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

Hi

út 15. 4. 2025 v 2:32 odesílatel Chapman Flack <jcflack(at)acm(dot)org> napsal:

> 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.
>

There was a long discussion, and I think the main reason for this design
is a possibility to use an old code without change although the
transformations are installed. And secondly there was a possibility to use
a transformation when it was installed, and use it although it was
installed after the function was created. For example PL/pgSQL code has no
dependency on types or casts that are internally used. And I can write code
in PL/Python that can work with or without transformation, and can be
unfriendly to force recreate functions to use a transformation. Today we
have more tools for processing dependencies in code, but 13 years ago the
possibility to work with PL code and transformations independently (how
much was possible) made sense. Today it is not a problem to build a new
production server and migrate data there, and there are less reasons to
maintain old servers. There was more expectation about others PL (than
PL/pgSQL) and about transformations (a lot of work where PLPerl was used
before can be done now by SQL/XML or SQL/JSON or by FDW).

https://www.postgresql.org/message-id/flat/1339713732.11971.79.camel%40vanquo.pezone.net

Regards

Pavel

>
> Regards,
> -Chap
>
>
>