From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chapman Flack <jcflack@acm.org>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Peter Eisentraut <peter@eisentraut.org>
Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming)
Date: Sun, 06 Apr 2025 20:01:51 -0400
Message-ID: <3112950.1743984111@sss.pgh.pa.us> (raw)
In-Reply-To: <67F30DDA.4000509@acm.org>
References: <67F2B767.9040507@acm.org>
<2965818.1743960827@sss.pgh.pa.us>
<67F2D87F.1000709@acm.org>
<2978258.1743968866@sss.pgh.pa.us>
<67F30DDA.4000509@acm.org>
Chapman Flack <jcflack@acm.org> writes:
> Only slightly tangentially: what things count as "objects that depend
> on the transform" for purposes of DROP TRANSFORM ... CASCADE / RESTRICT ?
> I just now dropped (in 17.4) a transform named in an existing routine's
> declaration, with nary a peep.
Hmm, really? ProcedureCreate() certainly looks like it creates
necessary dependencies, and when I tried it just now, I got the
expected failure:
regression=# create extension hstore_plperl;
CREATE EXTENSION
regression=# create function foo(f1 hstore) returns hstore language plperl
as 'return f1' transform for type hstore;
CREATE FUNCTION
regression=# drop extension hstore_plperl;
ERROR: cannot drop extension hstore_plperl because other objects depend on it
DETAIL: function foo(hstore) depends on transform for hstore language plperl
HINT: Use DROP ... CASCADE to drop the dependent objects too.
But wait a minute ... if I recreate the function with no
TRANSFORM clause, I *still* can't drop the transform:
regression=# drop function foo(f1 hstore);
DROP FUNCTION
regression=# create function foo(f1 hstore) returns hstore language plperl
as 'return f1';
CREATE FUNCTION
regression=# drop extension hstore_plperl;
ERROR: cannot drop extension hstore_plperl because other objects depend on it
DETAIL: function foo(hstore) depends on transform for hstore language plperl
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Looking more closely at ProcedureCreate(), it makes a dependency
if a transform *exists* for the argument or result type, whether
a TRANSFORM clause is present or not. Surely this is completely
bogus? We should be depending on the OIDs mentioned in protrftypes,
not more nor less.
I'm not quite sure if that somehow explains your results, but
it does look like a bug to me.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, jcflack@acm.org, peter@eisentraut.org
Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming)
In-Reply-To: <3112950.1743984111@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox