út 15. 4. 2025 v 2:32 odesílatel Chapman Flack <jcflack@acm.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).
