diff options
author | Andres Freund | 2022-03-08 02:30:57 +0000 |
---|---|---|
committer | Andres Freund | 2022-03-08 02:30:57 +0000 |
commit | 4228cabb72bb57e1df4c9d92613f1fcd4baadd5a (patch) | |
tree | 439d031a699c7af5a8de2cdf7a8c24a05773e073 | |
parent | 9b7e24a2cb37fb52af13219f625cd719e364a346 (diff) |
plpython: Adjust docs after removal of Python 2 support.
Reviewed-By: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/[email protected]
-rw-r--r-- | doc/src/sgml/hstore.sgml | 8 | ||||
-rw-r--r-- | doc/src/sgml/json.sgml | 9 | ||||
-rw-r--r-- | doc/src/sgml/ltree.sgml | 10 | ||||
-rw-r--r-- | doc/src/sgml/plpython.sgml | 289 | ||||
-rw-r--r-- | doc/src/sgml/ref/comment.sgml | 2 | ||||
-rw-r--r-- | doc/src/sgml/ref/create_transform.sgml | 6 | ||||
-rw-r--r-- | doc/src/sgml/ref/drop_transform.sgml | 4 |
7 files changed, 71 insertions, 257 deletions
diff --git a/doc/src/sgml/hstore.sgml b/doc/src/sgml/hstore.sgml index 870063c288..679878b3af 100644 --- a/doc/src/sgml/hstore.sgml +++ b/doc/src/sgml/hstore.sgml @@ -943,12 +943,8 @@ ALTER TABLE tablename ALTER hstorecol TYPE hstore USING hstorecol || ''; and <literal>hstore_plperlu</literal>, for trusted and untrusted PL/Perl. If you install these transforms and specify them when creating a function, <type>hstore</type> values are mapped to Perl hashes. The - extensions for PL/Python are - called <literal>hstore_plpythonu</literal>, <literal>hstore_plpython2u</literal>, - and <literal>hstore_plpython3u</literal> - (see <xref linkend="plpython-python23"/> for the PL/Python naming - convention). If you use them, <type>hstore</type> values are mapped to - Python dictionaries. + 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> diff --git a/doc/src/sgml/json.sgml b/doc/src/sgml/json.sgml index 673c70c3bb..c4223fafb6 100644 --- a/doc/src/sgml/json.sgml +++ b/doc/src/sgml/json.sgml @@ -716,12 +716,9 @@ UPDATE table_name SET jsonb_field[1]['a'] = '1'; </para> <para> - The extensions for PL/Python are called <literal>jsonb_plpythonu</literal>, - <literal>jsonb_plpython2u</literal>, and - <literal>jsonb_plpython3u</literal> (see <xref - linkend="plpython-python23"/> for the PL/Python naming convention). If you - use them, <type>jsonb</type> values are mapped to Python dictionaries, - lists, and scalars, as appropriate. + The extension for PL/Python is called <literal>jsonb_plpython3u</literal>. + If you use it, <type>jsonb</type> values are mapped to Python + dictionaries, lists, and scalars, as appropriate. </para> <para> diff --git a/doc/src/sgml/ltree.sgml b/doc/src/sgml/ltree.sgml index 436be76bfa..508f404ae8 100644 --- a/doc/src/sgml/ltree.sgml +++ b/doc/src/sgml/ltree.sgml @@ -826,19 +826,15 @@ ltreetest=> SELECT ins_label(path,2,'Space') FROM test WHERE path <@ 'Top. <title>Transforms</title> <para> - Additional extensions are available that implement transforms for - the <type>ltree</type> type for PL/Python. The extensions are - called <literal>ltree_plpythonu</literal>, <literal>ltree_plpython2u</literal>, - and <literal>ltree_plpython3u</literal> - (see <xref linkend="plpython-python23"/> for the PL/Python naming - convention). If you install these transforms and specify them when + The <literal>ltree_plpython3u</literal> extension implements transforms for + the <type>ltree</type> type for PL/Python. If installed and specified when 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 extensions be installed in + 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. diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml index b67f8f4aae..54355effd7 100644 --- a/doc/src/sgml/plpython.sgml +++ b/doc/src/sgml/plpython.sgml @@ -14,8 +14,7 @@ <para> To install PL/Python in a particular database, use - <literal>CREATE EXTENSION plpythonu</literal> (but - see also <xref linkend="plpython-python23"/>). + <literal>CREATE EXTENSION plpython3u</literal>. </para> <tip> @@ -28,14 +27,14 @@ <para> PL/Python is only available as an <quote>untrusted</quote> language, meaning it does not offer any way of restricting what users can do in it and - is therefore named <literal>plpythonu</literal>. A trusted + is therefore named <literal>plpython3u</literal>. A trusted variant <literal>plpython</literal> might become available in the future if a secure execution mechanism is developed in Python. The writer of a function in untrusted PL/Python must take care that the function cannot be used to do anything unwanted, since it will be able to do anything that could be done by a user logged in as the database administrator. Only superusers can create functions in - untrusted languages such as <literal>plpythonu</literal>. + untrusted languages such as <literal>plpython3u</literal>. </para> <note> @@ -47,140 +46,6 @@ </para> </note> - <sect1 id="plpython-python23"> - <title>Python 2 vs. Python 3</title> - - <para> - PL/Python supports both the Python 2 and Python 3 language - variants. (The PostgreSQL installation instructions might contain - more precise information about the exact supported minor versions - of Python.) Because the Python 2 and Python 3 language variants - are incompatible in some important aspects, the following naming - and transitioning scheme is used by PL/Python to avoid mixing them: - - <itemizedlist> - <listitem> - <para> - The PostgreSQL language named <literal>plpython2u</literal> - implements PL/Python based on the Python 2 language variant. - </para> - </listitem> - - <listitem> - <para> - The PostgreSQL language named <literal>plpython3u</literal> - implements PL/Python based on the Python 3 language variant. - </para> - </listitem> - - <listitem> - <para> - The language named <literal>plpythonu</literal> implements - PL/Python based on the default Python language variant, which is - currently Python 2. (This default is independent of what any - local Python installations might consider to be - their <quote>default</quote>, for example, - what <filename>/usr/bin/python</filename> might be.) The - default will probably be changed to Python 3 in a distant future - release of PostgreSQL, depending on the progress of the - migration to Python 3 in the Python community. - </para> - </listitem> - </itemizedlist> - - This scheme is analogous to the recommendations in <ulink - url="https://www.python.org/dev/peps/pep-0394/">PEP 394</ulink> regarding the - naming and transitioning of the <command>python</command> command. - </para> - - <para> - It depends on the build configuration or the installed packages - whether PL/Python for Python 2 or Python 3 or both are available. - </para> - - <tip> - <para> - The built variant depends on which Python version was found during - the installation or which version was explicitly set using - the <envar>PYTHON</envar> environment variable; - see <xref linkend="install-procedure"/>. To make both variants of - PL/Python available in one installation, the source tree has to be - configured and built twice. - </para> - </tip> - - <para> - This results in the following usage and migration strategy: - - <itemizedlist> - <listitem> - <para> - Existing users and users who are currently not interested in - Python 3 use the language name <literal>plpythonu</literal> and - don't have to change anything for the foreseeable future. It is - recommended to gradually <quote>future-proof</quote> the code - via migration to Python 2.6/2.7 to simplify the eventual - migration to Python 3. - </para> - - <para> - In practice, many PL/Python functions will migrate to Python 3 - with few or no changes. - </para> - </listitem> - - <listitem> - <para> - Users who know that they have heavily Python 2 dependent code - and don't plan to ever change it can make use of - the <literal>plpython2u</literal> language name. This will - continue to work into the very distant future, until Python 2 - support might be completely dropped by PostgreSQL. - </para> - </listitem> - - <listitem> - <para> - Users who want to dive into Python 3 can use - the <literal>plpython3u</literal> language name, which will keep - working forever by today's standards. In the distant future, - when Python 3 might become the default, they might like to - remove the <quote>3</quote> for aesthetic reasons. - </para> - </listitem> - - <listitem> - <para> - Daredevils, who want to build a Python-3-only operating system - environment, can change the contents of - <literal>plpythonu</literal>'s extension control and script files - to make <literal>plpythonu</literal> be equivalent - to <literal>plpython3u</literal>, keeping in mind that this - would make their installation incompatible with most of the rest - of the world. - </para> - </listitem> - </itemizedlist> - </para> - - <para> - See also the - document <ulink url="https://docs.python.org/3/whatsnew/3.0.html">What's - New In Python 3.0</ulink> for more information about porting to - Python 3. - </para> - - <para> - It is not allowed to use PL/Python based on Python 2 and PL/Python - based on Python 3 in the same session, because the symbols in the - dynamic modules would clash, which could result in crashes of the - PostgreSQL server process. There is a check that prevents mixing - Python major versions in a session, which will abort the session if - a mismatch is detected. It is possible, however, to use both - PL/Python variants in the same database, from separate sessions. - </para> - </sect1> - <sect1 id="plpython-funcs"> <title>PL/Python Functions</title> @@ -193,7 +58,7 @@ CREATE FUNCTION <replaceable>funcname</replaceable> (<replaceable>argument-list< RETURNS <replaceable>return-type</replaceable> AS $$ # PL/Python function body -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> </para> @@ -225,7 +90,7 @@ AS $$ if a > b: return a return b -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> The Python code that is given as the body of the function definition @@ -255,7 +120,7 @@ CREATE FUNCTION pystrip(x text) AS $$ x = x.strip() # error return x -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> because assigning to <varname>x</varname> makes <varname>x</varname> a local variable for the entire block, @@ -271,7 +136,7 @@ AS $$ global x x = x.strip() # ok now return x -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> But it is advisable not to rely on this implementation detail of PL/Python. It is better to treat the function parameters as @@ -303,11 +168,8 @@ $$ LANGUAGE plpythonu; <listitem> <para> - PostgreSQL <type>smallint</type> and <type>int</type> are - converted to Python <type>int</type>. - PostgreSQL <type>bigint</type> and <type>oid</type> are converted - to <type>long</type> in Python 2 and to <type>int</type> in - Python 3. + PostgreSQL <type>smallint</type>, <type>int</type>, <type>bigint</type> + and <type>oid</type> are converted to Python <type>int</type>. </para> </listitem> @@ -335,19 +197,15 @@ $$ LANGUAGE plpythonu; <listitem> <para> - PostgreSQL <type>bytea</type> is converted to - Python <type>str</type> in Python 2 and to <type>bytes</type> - in Python 3. In Python 2, the string should be treated as a - byte sequence without any character encoding. + PostgreSQL <type>bytea</type> is converted to Python <type>bytes</type>. </para> </listitem> <listitem> <para> - All other data types, including the PostgreSQL character string - types, are converted to a Python <type>str</type>. In Python - 2, this string will be in the PostgreSQL server encoding; in - Python 3, it will be a Unicode string like all strings. + All other data types, including the PostgreSQL character string types, + are converted to a Python <type>str</type> (in Unicode like all Python + strings). </para> </listitem> @@ -375,10 +233,10 @@ $$ LANGUAGE plpythonu; <listitem> <para> - When the PostgreSQL return type is <type>bytea</type>, the - return value will be converted to a string (Python 2) or bytes - (Python 3) using the respective Python built-ins, with the - result being converted to <type>bytea</type>. + When the PostgreSQL return type is <type>bytea</type>, the return value + will be converted to Python <type>bytes</type> using the respective + Python built-ins, with the result being converted to + <type>bytea</type>. </para> </listitem> @@ -393,14 +251,8 @@ $$ LANGUAGE plpythonu; </para> <para> - Strings in Python 2 are required to be in the PostgreSQL server - encoding when they are passed to PostgreSQL. Strings that are - not valid in the current server encoding will raise an error, - but not all encoding mismatches can be detected, so garbage - data can still result when this is not done correctly. Unicode - strings are converted to the correct encoding automatically, so - it can be safer and more convenient to use those. In Python 3, - all strings are Unicode strings. + Strings are automatically converted to the PostgreSQL server encoding + when they are passed to PostgreSQL. </para> </listitem> @@ -440,7 +292,7 @@ AS $$ if a > b: return a return b -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> As shown above, to return an SQL null value from a PL/Python @@ -461,10 +313,10 @@ CREATE FUNCTION return_arr() RETURNS int[] AS $$ return [1, 2, 3, 4, 5] -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; SELECT return_arr(); - return_arr + return_arr ------------- {1,2,3,4,5} (1 row) @@ -479,11 +331,11 @@ SELECT return_arr(); CREATE FUNCTION test_type_conversion_array_int4(x int4[]) RETURNS int4[] AS $$ plpy.info(x, type(x)) return x -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; SELECT * FROM test_type_conversion_array_int4(ARRAY[[1,2,3],[4,5,6]]); INFO: ([[1, 2, 3], [4, 5, 6]], <type 'list'>) - test_type_conversion_array_int4 + test_type_conversion_array_int4 --------------------------------- {{1,2,3},{4,5,6}} (1 row) @@ -506,7 +358,7 @@ CREATE FUNCTION return_str_arr() RETURNS varchar[] AS $$ return "hello" -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; SELECT return_str_arr(); return_str_arr @@ -540,7 +392,7 @@ AS $$ if (e["age"] < 30) and (e["salary"] > 100000): return True return False -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> </para> @@ -574,7 +426,7 @@ CREATE FUNCTION make_pair (name text, value integer) AS $$ return ( name, value ) # or alternatively, as list: return [ name, value ] -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> To return an SQL null for any column, insert <symbol>None</symbol> at @@ -600,7 +452,7 @@ CREATE FUNCTION make_pair (name text, value integer) RETURNS named_value AS $$ return { "name": name, "value": value } -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> Any extra dictionary key/value pairs are ignored. Missing keys are @@ -633,7 +485,7 @@ AS $$ nv.name = name nv.value = value return nv -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> </para> </listitem> @@ -646,7 +498,7 @@ $$ LANGUAGE plpythonu; <programlisting> CREATE FUNCTION multiout_simple(OUT i integer, OUT j integer) AS $$ return (1, 2) -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; SELECT * FROM multiout_simple(); </programlisting> @@ -657,7 +509,7 @@ SELECT * FROM multiout_simple(); <programlisting> CREATE PROCEDURE python_triple(INOUT a integer, INOUT b integer) AS $$ return (a * 3, b * 3) -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; CALL python_triple(5, 10); </programlisting> @@ -693,7 +545,7 @@ AS $$ # return tuple containing lists as composite types # all other combinations work also return ( [ how, "World" ], [ how, "PostgreSQL" ], [ how, "PL/Python" ] ) -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> </para> </listitem> @@ -724,7 +576,7 @@ AS $$ return ( self.how, self.who[self.ndx] ) return producer(how, [ "World", "PostgreSQL", "PL/Python" ]) -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> </para> </listitem> @@ -740,7 +592,7 @@ CREATE FUNCTION greet (how text) AS $$ for who in [ "World", "PostgreSQL", "PL/Python" ]: yield ( how, who ) -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> </para> @@ -756,7 +608,7 @@ $$ LANGUAGE plpythonu; <programlisting> CREATE FUNCTION multiout_simple_setof(n integer, OUT integer, OUT integer) RETURNS SETOF record AS $$ return [(1, 2)] * n -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; SELECT * FROM multiout_simple_setof(3); </programlisting> @@ -794,7 +646,7 @@ SELECT * FROM multiout_simple_setof(3); <programlisting> DO $$ # PL/Python code -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> An anonymous code block receives no arguments, and whatever value it @@ -1089,7 +941,7 @@ CREATE FUNCTION usesavedplan() RETURNS trigger AS $$ plan = plpy.prepare("SELECT 1") SD["plan"] = plan # rest of function -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> </para> </listitem> @@ -1132,7 +984,7 @@ for row in plpy.cursor("select num from largetable"): if row['num'] % 2: odd += 1 return odd -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; CREATE FUNCTION count_odd_fetch(batch_size integer) RETURNS integer AS $$ odd = 0 @@ -1145,7 +997,7 @@ while True: if row['num'] % 2: odd += 1 return odd -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; CREATE FUNCTION count_odd_prepared() RETURNS integer AS $$ odd = 0 @@ -1153,7 +1005,7 @@ plan = plpy.prepare("select num from largetable where num % $1 <> 0", ["in rows = list(plpy.cursor(plan, [2])) # or: = list(plan.cursor([2])) return len(rows) -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> </para> @@ -1198,7 +1050,7 @@ CREATE FUNCTION try_adding_joe() RETURNS text AS $$ return "something went wrong" else: return "Joe added" -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> </para> @@ -1231,7 +1083,7 @@ except plpy.SPIError as e: return "other error, SQLSTATE %s" % e.sqlstate else: return "fraction inserted" -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> Note that because all exceptions from the <literal>plpy.spiexceptions</literal> module inherit @@ -1280,7 +1132,7 @@ else: result = "funds transferred correctly" plan = plpy.prepare("INSERT INTO operations (result) VALUES ($1)", ["text"]) plpy.execute(plan, [result]) -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> If the second <literal>UPDATE</literal> statement results in an exception being raised, this function will report the error, but @@ -1312,7 +1164,7 @@ else: result = "funds transferred correctly" plan = plpy.prepare("INSERT INTO operations (result) VALUES ($1)", ["text"]) plpy.execute(plan, [result]) -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; </programlisting> Note that the use of <literal>try/catch</literal> is still required. Otherwise the exception would propagate to the top of @@ -1329,44 +1181,6 @@ $$ LANGUAGE plpythonu; to be rolled back. </para> </sect2> - - <sect2> - <title>Older Python Versions</title> - - <para> - Context managers syntax using the <literal>with</literal> keyword - is available by default in Python 2.6. For compatibility with - older Python versions, you can call the - subtransaction manager's <literal>__enter__</literal> and - <literal>__exit__</literal> functions using the - <literal>enter</literal> and <literal>exit</literal> convenience - aliases. The example function that transfers funds could be - written as: -<programlisting> -CREATE FUNCTION transfer_funds_old() RETURNS void AS $$ -try: - subxact = plpy.subtransaction() - subxact.enter() - try: - plpy.execute("UPDATE accounts SET balance = balance - 100 WHERE account_name = 'joe'") - plpy.execute("UPDATE accounts SET balance = balance + 100 WHERE account_name = 'mary'") - except: - import sys - subxact.exit(*sys.exc_info()) - raise - else: - subxact.exit(None, None, None) -except plpy.SPIError as e: - result = "error transferring funds: %s" % e.args -else: - result = "funds transferred correctly" - -plan = plpy.prepare("INSERT INTO operations (result) VALUES ($1)", ["text"]) -plpy.execute(plan, [result]) -$$ LANGUAGE plpythonu; -</programlisting> - </para> - </sect2> </sect1> <sect1 id="plpython-transactions"> @@ -1389,7 +1203,7 @@ $$ LANGUAGE plpythonu; Here is an example: <programlisting> CREATE PROCEDURE transaction_test1() -LANGUAGE plpythonu +LANGUAGE plpython3u AS $$ for i in range(0, 10): plpy.execute("INSERT INTO test1 (a) VALUES (%d)" % i) @@ -1465,7 +1279,7 @@ CREATE FUNCTION raise_custom_exception() RETURNS void AS $$ plpy.error("custom exception message", detail="some info about exception", hint="hint for users") -$$ LANGUAGE plpythonu; +$$ LANGUAGE plpython3u; =# SELECT raise_custom_exception(); ERROR: plpy.Error: custom exception message @@ -1496,6 +1310,17 @@ plpy.execute("UPDATE tbl SET %s = %s WHERE key = %s" % ( </para> </sect1> + <sect1 id="plpython-python23"> + <title>Python 2 vs. Python 3</title> + + <para> + PL/Python supports only Python 3. Past versions of + <productname>PostgreSQL</productname> supported Python 2, using the + <literal>plpythonu</literal> and <literal>plpython2u</literal> language + names. + </para> + </sect1> + <sect1 id="plpython-envar"> <title>Environment Variables</title> diff --git a/doc/src/sgml/ref/comment.sgml b/doc/src/sgml/ref/comment.sgml index b12796095f..23d9029af9 100644 --- a/doc/src/sgml/ref/comment.sgml +++ b/doc/src/sgml/ref/comment.sgml @@ -349,7 +349,7 @@ COMMENT ON TEXT SEARCH CONFIGURATION my_config IS 'Special word filtering'; COMMENT ON TEXT SEARCH DICTIONARY swedish IS 'Snowball stemmer for Swedish language'; COMMENT ON TEXT SEARCH PARSER my_parser IS 'Splits text into words'; COMMENT ON TEXT SEARCH TEMPLATE snowball IS 'Snowball stemmer'; -COMMENT ON TRANSFORM FOR hstore LANGUAGE plpythonu IS 'Transform between hstore and Python dict'; +COMMENT ON TRANSFORM FOR hstore LANGUAGE plpython3u IS 'Transform between hstore and Python dict'; COMMENT ON TRIGGER my_trigger ON my_table IS 'Used for RI'; COMMENT ON TYPE complex IS 'Complex number data type'; COMMENT ON VIEW my_view IS 'View of departmental costs'; diff --git a/doc/src/sgml/ref/create_transform.sgml b/doc/src/sgml/ref/create_transform.sgml index 3f81dc6bba..34bdc60e13 100644 --- a/doc/src/sgml/ref/create_transform.sgml +++ b/doc/src/sgml/ref/create_transform.sgml @@ -156,11 +156,11 @@ CREATE [ OR REPLACE ] TRANSFORM FOR <replaceable>type_name</replaceable> LANGUAG <para> To create a transform for type <type>hstore</type> and language - <literal>plpythonu</literal>, first set up the type and the language: + <literal>plpython3u</literal>, first set up the type and the language: <programlisting> CREATE TYPE hstore ...; -CREATE EXTENSION plpythonu; +CREATE EXTENSION plpython3u; </programlisting> Then create the necessary functions: <programlisting> @@ -174,7 +174,7 @@ AS ...; </programlisting> And finally create the transform to connect them all together: <programlisting> -CREATE TRANSFORM FOR hstore LANGUAGE plpythonu ( +CREATE TRANSFORM FOR hstore LANGUAGE plpython3u ( FROM SQL WITH FUNCTION hstore_to_plpython(internal), TO SQL WITH FUNCTION plpython_to_hstore(internal) ); diff --git a/doc/src/sgml/ref/drop_transform.sgml b/doc/src/sgml/ref/drop_transform.sgml index d25cb51604..544a9663d7 100644 --- a/doc/src/sgml/ref/drop_transform.sgml +++ b/doc/src/sgml/ref/drop_transform.sgml @@ -101,9 +101,9 @@ DROP TRANSFORM [ IF EXISTS ] FOR <replaceable>type_name</replaceable> LANGUAGE < <para> To drop the transform for type <type>hstore</type> and language - <literal>plpythonu</literal>: + <literal>plpython3u</literal>: <programlisting> -DROP TRANSFORM FOR hstore LANGUAGE plpythonu; +DROP TRANSFORM FOR hstore LANGUAGE plpython3u; </programlisting></para> </refsect1> |