Re: transforms

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

In response to

Responses

Browse pgsql-hackers by date

  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