Re: Appetite for syntactic sugar to match result set columns to UDT fields?

While you are correct that the structure will create a UDT (which is how
I framed a possible solution to the larger problem in my second
message), the example:

Begin
...

Return Query
Select T1.T1F7 as F1, T2.T2F3 as F2, Tp.Fq as Fn
From T1 Join T2 On...Join...Tp
Where...
...
End;

Becomes quite ugly (and perhaps inefficient?):

Begin
...

Return Query
Select (FOO(F1:=T1.T1F7, F2:=T2.T2F3), ..., Fn:=Tp.Fq)).*
From T1 Join T2 On...Join...Tp
Where...
...
End;

The (FOO(F1:=T1.T1F7, F2:=T2.T2F3), ..., Fn:=Tp.Fq)).* looks ugly, at
least, and it required because of the return type.

Perhaps I need to go back to the original "syntactic sugar" concept so
that we can achieve a "correct" row structure when the code is parsed,
not by calling runtime functions (constructors)?

They key here is that we know the type that needs to be returned (or we
can specify it in SQL _somehow_); it would be good if the parser could
perform the tasks to make sure that the row structure matched the type
requirement.

On 2025-09-06 00:08, Tom Lane wrote:

> Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>
>> I'd like a formulation like:
>> Select Row(T1.T1F7 as F1, T2.T2F3 as F2, Tp.Fq as Fn)::FOO By Name
>> Or
>> Select FOO(F1:=T1.T1F7, F2:=T2.T2F3, Fn:=Tp.Fq)
>
>> Basically: it's some form of UDT constructor with named parameters,
>> whether by cast, pseudo function call or some other mechanism.
>
> Well, you can build a real function call that does that:
>
> CREATE FUNCTION FOO(F1 int, F2 int, ...) RETURNS FOO AS ...;
>
> SELECT FOO(F1 => T1.T1F7, F2 => T2.T2F3, ...) FROM ...;
>
> Admittedly you have to get the ROW() constructor right in the
> body of function FOO, but then you've got it. This approach
> also lets you insert appropriate default values for unspecified
> columns, which is a feature we surely wouldn't build in if this
> were wired-in syntax.
>
> regards, tom lane