Re: FmgrInfo allocation patterns (and PL handling as staged programming) - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: FmgrInfo allocation patterns (and PL handling as staged programming)
Date
Msg-id 67FDA91C.1060909@acm.org
Whole thread Raw
In response to Re: FmgrInfo allocation patterns (and PL handling as staged programming)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: FmgrInfo allocation patterns (and PL handling as staged programming)
Re: FmgrInfo allocation patterns (and PL handling as staged programming)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment
Next
From: jian he
Date:
Subject: Re: bug in stored generated column over domain with constraints.