Re: UNNEST with multiple args, and TABLE with multiple funcs - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: UNNEST with multiple args, and TABLE with multiple funcs
Date
Msg-id 878uwhwv0i.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: UNNEST with multiple args, and TABLE with multiple funcs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: UNNEST with multiple args, and TABLE with multiple funcs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> Anyway, after further thought I've come up with an approachTom> that's purely a syntactic transformation and so
lesslikely toTom> cause surprise: let's say that if we have TABLE() with a singleTom> argument, and no coldeflist
eitherinside or outside, then weTom> implicitly insert UNNEST().  Otherwise not.
 

This seems ugly beyond belief.

Specifically, having TABLE(foo()) and TABLE(foo(),bar()) be radically
different constructs, and likewise  TABLE(foo()) and TABLE(foo() AS (...)),
strikes me as highly objectionable.

If there isn't a reasonable syntax alternative to TABLE(...) for the
multiple functions case, then frankly I think we should go ahead and
burn compatibility with a spec feature which appears to be of negative
value.

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Sawada Masahiko
Date:
Subject: Re: Logging WAL when updating hintbit
Next
From: Heikki Linnakangas
Date:
Subject: Re: gaussian distribution pgbench