On 04/19/25 19:32, Chapman Flack wrote:
> 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 t
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
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
On 04/19/25 15:03, Tom Lane wrote:
> So what are the odds that outside PLs do it correctly (for whatever
> you think "correctly" is)? It doesn't help any that we document
> none of this.
My sense of Déjà vu turns out to be because I had a bunch of proposed
new documentation and example code for p
BTW, there is another way in which the current rules for transform
application are not self-consistent. Postgres has three kinds of
container types: arrays, composites, and ranges. But the transform
code special-cases only arrays. I'd have thought that if the idea is
to specify transforms only f
Chapman Flack writes:
>Therefore:
> 5. You can create a transform for an array type, but can never refer to it
>in TRANSFORM FOR TYPE (you end up referring to the element type).
> 6. You can refer to a domain in TRANSFORM FOR TYPE, but that transform
>can never be created.
> These don'
Also noticing about transforms:
1. protrftypes can have duplicates.
In part, this is because CreateFunction does nothing to stop you saying
redundant things like TRANSFORM FOR TYPE circle, FOR TYPE circle.
But it is also because:
2. CreateFunction hands every type seen in TRANSFORM FOR
On 04/15/25 23:39, Tom Lane wrote:
> My own beef with the whole setup is that you can't specify *which*
> arguments or results you want transformed. I don't believe that
> this should have been keyed off data types to begin with. But
> that design was the SQL committee's choice so we're stuck ...
Chapman Flack writes:
> On 04/15/25 10:52, Tom Lane wrote:
>> The problem from a PL's standpoint is "given this input or output
>> of type FOO, should I transform it, and if so using what?". So
>> the starting point has to be a type not a transform.
> Perhaps the efficiency argument is really "s
