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