Use @extschema:name@ notation in contrib transform modules.

Harden hstore_plperl, hstore_plpython, and ltree_plpython
against search-path-based attacks by using @extschema:name@
notation to refer to the underlying hstore or ltree data type.

This allows removal of the previous documentation warning
suggesting that they must be installed in the same schema as
the underlying data type.  In passing, also improve a para in
extend.sgml to suggest using @extschema:name@ for such purposes.

Discussion: https://postgr.es/m/692480.1736021695@sss.pgh.pa.us

contrib/hstore_plperl/hstore_plperl--1.0.sql

@@ -7,11 +7,11 @@ CREATE FUNCTION hstore_to_plperl(val internal) RETURNS internal
 LANGUAGE C STRICT IMMUTABLE
 AS 'MODULE_PATHNAME';
 
-CREATE FUNCTION plperl_to_hstore(val internal) RETURNS hstore
+CREATE FUNCTION plperl_to_hstore(val internal) RETURNS @extschema:hstore@.hstore
 LANGUAGE C STRICT IMMUTABLE
 AS 'MODULE_PATHNAME';
 
-CREATE TRANSFORM FOR hstore LANGUAGE plperl (
+CREATE TRANSFORM FOR @extschema:hstore@.hstore LANGUAGE plperl (
     FROM SQL WITH FUNCTION hstore_to_plperl(internal),
     TO SQL WITH FUNCTION plperl_to_hstore(internal)
 );

contrib/hstore_plperl/hstore_plperlu--1.0.sql

@@ -7,11 +7,11 @@ CREATE FUNCTION hstore_to_plperlu(val internal) RETURNS internal
 LANGUAGE C STRICT IMMUTABLE
 AS 'MODULE_PATHNAME', 'hstore_to_plperl';
 
-CREATE FUNCTION plperlu_to_hstore(val internal) RETURNS hstore
+CREATE FUNCTION plperlu_to_hstore(val internal) RETURNS @extschema:hstore@.hstore
 LANGUAGE C STRICT IMMUTABLE
 AS 'MODULE_PATHNAME', 'plperl_to_hstore';
 
-CREATE TRANSFORM FOR hstore LANGUAGE plperlu (
+CREATE TRANSFORM FOR @extschema:hstore@.hstore LANGUAGE plperlu (
     FROM SQL WITH FUNCTION hstore_to_plperlu(internal),
     TO SQL WITH FUNCTION plperlu_to_hstore(internal)
 );

contrib/hstore_plpython/hstore_plpython3u--1.0.sql

@@ -7,13 +7,13 @@ CREATE FUNCTION hstore_to_plpython3(val internal) RETURNS internal
 LANGUAGE C STRICT IMMUTABLE
 AS 'MODULE_PATHNAME', 'hstore_to_plpython';
 
-CREATE FUNCTION plpython3_to_hstore(val internal) RETURNS hstore
+CREATE FUNCTION plpython3_to_hstore(val internal) RETURNS @extschema:hstore@.hstore
 LANGUAGE C STRICT IMMUTABLE
 AS 'MODULE_PATHNAME', 'plpython_to_hstore';
 
-CREATE TRANSFORM FOR hstore LANGUAGE plpython3u (
+CREATE TRANSFORM FOR @extschema:hstore@.hstore LANGUAGE plpython3u (
     FROM SQL WITH FUNCTION hstore_to_plpython3(internal),
     TO SQL WITH FUNCTION plpython3_to_hstore(internal)
 );
 
-COMMENT ON TRANSFORM FOR hstore LANGUAGE plpython3u IS 'transform between hstore and Python dict';
+COMMENT ON TRANSFORM FOR @extschema:hstore@.hstore LANGUAGE plpython3u IS 'transform between hstore and Python dict';

contrib/ltree_plpython/ltree_plpython3u--1.0.sql

@@ -7,6 +7,6 @@ CREATE FUNCTION ltree_to_plpython3(val internal) RETURNS internal
 LANGUAGE C STRICT IMMUTABLE
 AS 'MODULE_PATHNAME', 'ltree_to_plpython';
 
-CREATE TRANSFORM FOR ltree LANGUAGE plpython3u (
+CREATE TRANSFORM FOR @extschema:ltree@.ltree LANGUAGE plpython3u (
     FROM SQL WITH FUNCTION ltree_to_plpython3(internal)
 );

doc/src/sgml/extend.sgml

@@ -1348,15 +1348,11 @@ SELECT * FROM pg_extension_update_paths('<replaceable>extension_name</replaceabl
      </para>
 
      <para>
-      Cross-extension references are extremely difficult to make fully
-      secure, partially because of uncertainty about which schema the other
-      extension is in.  The hazards are reduced if both extensions are
-      installed in the same schema, because then a hostile object cannot be
-      placed ahead of the referenced extension in the installation-time
-      <varname>search_path</varname>.  However, no mechanism currently exists
-      to require that.  For now, best practice is to not mark an extension
-      trusted if it depends on another one, unless that other one is always
-      installed in <literal>pg_catalog</literal>.
+      Secure cross-extension references typically require schema-qualification
+      of the names of the other extension's objects, using the
+      <literal>@extschema:<replaceable>name</replaceable>@</literal>
+      syntax, in addition to careful matching of argument types for functions
+      and operators.
      </para>
     </sect3>
    </sect2>

doc/src/sgml/hstore.sgml

@@ -946,15 +946,6 @@ ALTER TABLE tablename ALTER hstorecol TYPE hstore USING hstorecol || '';
    extension for PL/Python is called <literal>hstore_plpython3u</literal>.
    If you use it, <type>hstore</type> values are mapped to Python dictionaries.
   </para>
-
-  <caution>
-   <para>
-    It is strongly recommended that the transform extensions be installed in
-    the same schema as <filename>hstore</filename>.  Otherwise there are
-    installation-time security hazards if a transform extension's schema
-    contains objects defined by a hostile user.
-   </para>
-  </caution>
  </sect2>
 
  <sect2 id="hstore-authors">

doc/src/sgml/ltree.sgml

@@ -841,15 +841,6 @@ ltreetest=> SELECT ins_label(path,2,'Space') FROM test WHERE path <@ 'Top.
    creating a function, <type>ltree</type> values are mapped to Python lists.
    (The reverse is currently not supported, however.)
   </para>
-
-  <caution>
-   <para>
-    It is strongly recommended that the transform extension be installed in
-    the same schema as <filename>ltree</filename>.  Otherwise there are
-    installation-time security hazards if a transform extension's schema
-    contains objects defined by a hostile user.
-   </para>
-  </caution>
  </sect2>
 
  <sect2 id="ltree-authors">