Reason why set-value functions not allowed in GREATEST(), etc?
in [PgSql]
|
Prev: Wire protocol docs
Next: [HACKERS] tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)
From: Pavel Stehule on 22 Feb 2010 13:16 2010/2/22 Hitoshi Harada <umi.tanuki(a)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(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 22 Feb 2010 15:24
Hitoshi Harada <umi.tanuki(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |