Skip site navigation (1) Skip section navigation (2)

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

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)postgresql(dot)org>
Cc: 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 12:26:25
Message-ID: 87fy4ej40e.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
"Tom Lane" <tgl(at)postgresql(dot)org> writes:

> For the moment, lie about WITH's status in the table so it will still get
> quoted --- this is because of the expectation that WITH will become reserved
> when the SQL recursive-queries patch gets done.

Out of curiosity I'm checking what consequences some other future grammer
changes might have for us. Today I checked out full spec compliant GROUP BY
syntax including ROLLUP, CUBE, and GROUPING SETS.

There are two conclusions of note:

1) ROLLUP and CUBE would have to be col_name_keyword keywords. 

   That could be an annoyance for the cube contrib package because it defines
   a few constructors like cube(float8[]). You could still have a type named
   "cube" but the functions would have to be renamed. Personally I always
   found "cube" a strange name anyways, I think of this data type more as a
   n-space vector than a cube anyways.

   quote_identifier would start quoting "cube" and "rollup" everywhere. My
   first inclination was that it's probably not necessary to start
   preemptively quoting them this release because people are more likely to
   use them as column names than function names anyways. But perhaps that's
   not true given the contrib module.

2) Assuming we keep our extension of allowing arbitrary expressions in GROUP
   BY lists then there is a conflict between our undecorated row constructor
   '(' expr_list ')' and the spec which allows parenthesized sublists in the
   grouping list.

   I'm not sure this is a real problem though. As near as I can tell the
   semantics of grouping by a ROW(a,b) and grouping by columns (a,b) as a
   grouping set element are basically the same anyways. So I think we can just
   accept any arbitrary expression including row constructors as what the spec
   calls an "ordinary grouping set".




For what it's worth here's the grammar I get by basically copying the grammar
straight out of the spec and then cleaning up the conflicts including making
ordinary_grouping_set a straight expr_list as described above:

opt_group_set_clause:
            DISTINCT
            | ALL
            | /*EMPTY*/
        ;

group_clause:
            GROUP_P BY opt_group_set_clause grouping_element_list
            | /*EMPTY*/
        ;

grouping_element_list:
    grouping_element
    | grouping_element_list ',' grouping_element
    ;

grouping_element:
    a_expr
    | rollup_list
    | cube_list
    | grouping_sets_specification
    | empty_grouping_set
    ;

rollup_list:
    ROLLUP '(' expr_list ')'
    ;

cube_list:
    CUBE '(' expr_list ')'
    ;

grouping_sets_specification:
    GROUPING SETS '(' grouping_set_list ')'
    ;

grouping_set_list:
    grouping_set
    | grouping_set_list ',' grouping_set
    ;

grouping_set:
    a_expr
    | rollup_list
    | cube_list
    | grouping_sets_specification
    | empty_grouping_set
    ;

empty_grouping_set: '(' ')'
    ;

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


In response to

Responses

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-06-26 13:49:51
Subject: Re: [COMMITTERS] pgsql: Arrange for quote_identifier() and pg_dump to not quote keywords
Previous:From: Robert TreatDate: 2007-06-26 12:18:17
Subject: Re: How do we create the releases?

pgsql-committers by date

Next:From: Gregory StarkDate: 2007-06-26 13:49:51
Subject: Re: [COMMITTERS] pgsql: Arrange for quote_identifier() and pg_dump to not quote keywords
Previous:From: Magnus HaganderDate: 2007-06-26 11:43:56
Subject: pgsql: Add extra checks for buildfarm to pick up errors when running on

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group