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

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:05:11
Message-ID: 878uwhwv0i.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-11-21 17:13:25 Re: gaussian distribution pgbench
Previous Message Sawada Masahiko 2013-11-21 16:56:38 Re: Logging WAL when updating hintbit