Re: transforms
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chapman Flack <jcflack@acm.org>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Peter Eisentraut <peter@eisentraut.org>,
Pavel Stehule <pavel.stehule@gmail.com>
Date: 2025-04-19T23:12:58Z
Lists: pgsql-hackers
Oh, just in case this wasn't complicated enough already: what to do with polymorphic arguments/results? You could argue that CREATE FUNCTION foo(anyelement) RETURNS anyelement TRANSFORM FOR TYPE int AS ...; should mean that if the actual argument type is int, then the mentioned transform should be applied to the input and result; but if it's some other type then just do the normal conversions. You could perhaps also argue that that's a bad idea. I'm not sure. It does make for very dynamic matching of transforms to arguments, which feels dubious to me, but I can't put my finger on a bad consequence. We have not faced this issue in the in-core PLs because neither plperl nor plpython allow polymorphic arguments/results. (I'm surprised that no one has yet wanted to fix that.) But I will bet that there are other PLs that do allow that, and if they also implement transforms then there's probably precedent out there already. regards, tom lane
Commits
-
Fix erroneous construction of functions' dependencies on transforms.
- b73e6d71a89f 18.0 landed
-
Change SQL-language functions to use the plan cache.
- 0dca5d68d7be 18.0 cited