Subject: Re: FmgrInfo allocation patterns (and PL handling as staged
 programming)
To: Tom Lane <tgl@sss.pgh.pa.us>
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> <3112950.1743984111@sss.pgh.pa.us>
 <67F31F20.6090706@acm.org> <3291225.1743993461@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 Peter Eisentraut <peter@eisentraut.org>
From: Chapman Flack <jcflack@acm.org>
Message-ID: <67FDA91C.1060909@acm.org>
Date: Mon, 14 Apr 2025 20:32:28 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <3291225.1743993461@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/67FDA91C.1060909%40acm.org>
Precedence: bulk

On 04/06/25 22:37, Tom Lane wrote:
> Here's a draft patch to fix the bogus dependencies.  As given this'd
> only be okay for HEAD, since I doubt we can get away with changing
> ProcedureCreate()'s signature in stable branches ... In the back branches
> we could make ProcedureCreate() deconstruct the OID array it's given and
> then repeat the transform lookups, but ugh. ...
> 
> BTW, I feel a little uncomfortable with the idea that we're adding
> dependencies on objects that are explicitly mentioned nowhere in the
> pg_proc entry.

Pursuing that idea a bit further, was there a compelling original reason
the column in pg_proc had to be protrftypes and not just protransforms?

The transforms have been looked up at ProcedureCreate time.

Any PL that supports transforms has to repeat the transform lookups
if there are protrftypes present.

Any PL that doesn't support transforms needs only to check for presence
and say "sorry, I don't support those", which it could do just as easily
with a list of transforms as with a list of types.

Regards,
-Chap