Re: Reason why set-value functions not allowed in GREATEST(), etc?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reason why set-value functions not allowed in GREATEST(), etc?
Date: 2010-02-22 20:24:54
Message-ID: 701.1266870294@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-22 20:30:48 Re: What does this configure warning mean?
Previous Message Merlin Moncure 2010-02-22 20:15:03 Re: scheduler in core