From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chapman Flack <jcflack(at)acm(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Subject: | Re: transforms |
Date: | 2025-04-19 23:12:58 |
Message-ID: | 135173.1745104378@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2025-04-19 23:32:16 | Re: transforms |
Previous Message | Michael Paquier | 2025-04-19 22:57:39 | Re: Rename injection point names in test_aio |