| 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: | Whole Thread | Raw Message | 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 |