Re: FmgrInfo allocation patterns (and PL handling as staged programming)

From: Chapman Flack <jcflack(at)acm(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming)
Date: 2025-04-15 00:32:28
Message-ID: 67FDA91C.1060909@acm.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-04-15 00:37:53 Re: bug in stored generated column over domain with constraints.
Previous Message David Rowley 2025-04-15 00:23:11 Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment