Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
От | Thomas Lockhart |
---|---|
Тема | Re: RI and PARSER (was: Re: [HACKERS] RI status report #1) |
Дата | |
Msg-id | 37F19876.D0852A9B@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: RI and PARSER (was: Re: [HACKERS] RI status report #1) (wieck@debis.com (Jan Wieck)) |
Ответы |
Re: RI and PARSER (was: Re: [HACKERS] RI status report #1)
|
Список | pgsql-hackers |
> Just tell me which of these SQL3 "reserved" keywords > (according to the SQL3 draft I got from Vadim) should be > available for column ID or Label: > CONSTRAINTS > DEFERRABLE > DEFERRED > IMMEDIATE > INITIALLY > PENDANT > RESTRICT > Then I'll add them before committing. Overlooking the syntax > of my new commands, it wouldn't hurt to add them all to these > lists. But should SQL3 reserved words really be in them? We have tried to allow as many keywords as possible for identifiers (for ColId, which includes ColLabel) or, as a more limited choice, for column aliases (ColLabel only). This is particularly helpful as we implement more and more of the standard, and take away previously allowed column and table names. The keywords, reserved, unreserved, and unused, are documented for Postgres in syntax.sgml, and the docs present them wrt the SQL92 and SQL3 standards. What I usually do is try adding one or all of them to ColId, and if that fails by giving shift/reduce conflicts I'll try moving the offenders to ColLabel. There aren't many places in the syntax where yacc/bison can't handle keywords at least as column labels. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: