Re: [COMMITTERS] pgsql: Arrange for quote_identifier() and pg_dump to not quote keywords

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Arrange for quote_identifier() and pg_dump to not quote keywords
Date: 2007-06-26 16:11:28
Message-ID: 22710.1182874288@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Also, the fact that this particular form of the grammar requires
>> reserving the keywords does not prove that there is no way to have the
>> features without that. I'd want to see us try a little harder first.

> At least some of them are unavoidable conflicts:

> select a,b,count(*) from tab GROUP BY cube(a,b)
> select a,b,count(*) from tab GROUP BY rollup(a,b)

In principle this case could be handled by having parse analysis
treat a FuncCall node at the top level of GROUP BY specially when
the function name is CUBE etc.

I'm not saying that might not be uglier than having the grammar
recognize it, just pointing out that there's usually more than
one way to skin a cat.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2007-06-26 16:48:09 pgsql: Remove unused "caller" argument from stringToQualifiedNameList.
Previous Message Gregory Stark 2007-06-26 15:45:51 Re: [COMMITTERS] pgsql: Arrange for quote_identifier() and pg_dump to not quote keywords

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Hammond 2007-06-26 18:10:56 Re: Bugtraq: Having Fun With PostgreSQL
Previous Message Tom Lane 2007-06-26 15:59:49 Re: [PATCHES] New Zealand - TZ change