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

From Tom Lane
Subject Re: UNNEST with multiple args, and TABLE with multiple funcs
Date
Msg-id 6975.1385054577@sss.pgh.pa.us
Whole thread Raw
In response to Re: UNNEST with multiple args, and TABLE with multiple funcs  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: UNNEST with multiple args, and TABLE with multiple funcs  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: UNNEST with multiple args, and TABLE with multiple funcs  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> Anyway, after further thought I've come up with an approach
>  Tom> that's purely a syntactic transformation and so less likely to
>  Tom> cause surprise: let's say that if we have TABLE() with a single
>  Tom> argument, and no coldeflist either inside or outside, then we
>  Tom> implicitly insert UNNEST().  Otherwise not.

> This seems ugly beyond belief.

True :-(

> 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.

TBH, I'm getting close to that conclusion too.  The more I look at the
spec, the more I think it must be a mistake, or else I'm somehow reading
it wrong, because it sure makes no sense for them to have invented
something that's just an alternative and less-clear syntax for a feature
they already had.

Can anyone who's following this thread check the behavior of Oracle or
DB2 to see if they interpret TABLE() the way I think the spec says?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: gaussian distribution pgbench
Next
From: Andres Freund
Date:
Subject: Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1