| From: | Chapman Flack <jcflack(at)acm(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:32:16 |
| Message-ID: | 68043280.1010305@acm.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04/19/25 19:12, Tom Lane wrote:
> 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.
My position would be that it's not a bad idea. It would be consistent
and unastonishing.
A PL that uses a staging approach has probably precomputed and cached
a good deal of information, including what transforms are requested and
what parameter positions are polymorphic if any, and only needs to check
those when specializing, and funccache can preserve those results too.
Regards,
-Chap
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chapman Flack | 2025-04-19 23:50:47 | Re: transforms |
| Previous Message | Tom Lane | 2025-04-19 23:12:58 | Re: transforms |