Re: UNNEST with multiple args, and TABLE with multiple funcs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: David Johnston <polobo(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: UNNEST with multiple args, and TABLE with multiple funcs
Date: 2013-11-21 17:22:57
Message-ID: 6975.1385054577@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-11-21 17:23:53 Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
Previous Message Heikki Linnakangas 2013-11-21 17:13:25 Re: gaussian distribution pgbench