Обсуждение: Reason why set-value functions not allowed in GREATEST(), etc?

I just wonder why generate_series() is not allowed in GREATEST syntax.
Looking through execQual.c,  almost all syntactic evaluations like
COALESCE, ARRAY[], ROW() doesn't allow set-value functions. Could
someone tell the underlying reason?

Also, using variadic functions introduced since 8.4, I hope we can
remove the special syntax cases for them by replacing them with normal
variadic functions. Is it sane idea?

Regards,

-- 
Hitoshi Harada

2010/2/22 Hitoshi Harada <umi.tanuki@gmail.com>:
> I just wonder why generate_series() is not allowed in GREATEST syntax.
> Looking through execQual.c,  almost all syntactic evaluations like
> COALESCE, ARRAY[], ROW() doesn't allow set-value functions. Could
> someone tell the underlying reason?
>
> Also, using variadic functions introduced since 8.4, I hope we can
> remove the special syntax cases for them by replacing them with normal
> variadic functions. Is it sane idea?

we cannot do it :(

we cannot ensure similar coercion for these functions with variadic
functions. Variadic functions use a generic coercion.

Regards
Pavel Stehule

>
> Regards,
>
> --
> Hitoshi Harada
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Hitoshi Harada <umi.tanuki@gmail.com> writes:
> I just wonder why generate_series() is not allowed in GREATEST syntax.
> Looking through execQual.c,  almost all syntactic evaluations like
> COALESCE, ARRAY[], ROW() doesn't allow set-value functions. Could
> someone tell the underlying reason?

Laziness, or lack of return for the effort, or lack of desire to extend
a semantically dubious behavior even further, as you prefer.

You could support at most one set-returning input (at least without an
order of magnitude increase in complexity and creating even more room
for semantic debate), and keeping track of which one is the set would be
a PITA.  Essentially you'd need to add something of about the complexity
of ExecTargetList() to each one of those special purpose functions.

The other reason is that a lot of us think that SRFs in the targetlist
are not a feature we want to encourage anyway.  The semantics are either
dubious or outright broken depending on who you ask.  And from a
performance standpoint, adding any more complexity to execQual nodes is
not a sane thing to be doing.  What we ought to do is implement LATERAL
and tell people to move in that direction.
        regards, tom lane