Grzegorz Jaskiewicz <g...@pointblue.com.pl> writes: > On 31 Jan 2009, at 17:17, Gregory Stark wrote: >> >> I don't see any reason offhand why it should have to be a reserved word >> though. You should be able to make it an UNRESERVED_KEYWORD. Oh, and you'll >> want to add it to the list of tokens in unreserved_keyword in gram.y as >> well. > > removing it from keywords.c and adding it to unserserved_keywords crowd > didn't > make it... so I'll stick with keywords.c for timebeing.
I'm sorry if I was unclear. It needs to be in keywords.c but can probably be marked as UNRESERVED_KEYWORD there rather than RESERVED_KEYWORD. It has to be in the grammar rule for the corresponding production, either reserved_keyword or unreserved_keyword. In other words there are two places where you have to indicate whether it's reserved or not, keywords.c and gram.y. > So far I got mostly critique here, even tho - I haven't started much, which > is > quite sad in a way - because it is not very pro-creative, but I'll still > continue on with the patch - whatever the outcome. Any change to the grammar meets the question of whether it conflicts with the standard. That's just the way it is and doesn't reflect on you or your work. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
