From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] RFC: create/alter user extension |
Date: | 1999-11-13 14:57:08 |
Message-ID: | 318.942505028@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE> writes:
>> I'd be inclined to go with UID or SYSID. In any case, since the new
>> keyword is used in such a limited context, we could almost certainly
>> still allow it as a ColId and thus not create any real compatibility
>> problem.
> I'm not sure about this distinction. Where would that be reflected in the
> (parser) code?
You should try to add this (or any other) new keyword to the list in the
ColId: production in gram.y. If that doesn't provoke any complaints
from yacc (shift/reduce conflicts etc), then you're home free: the
parser won't get confused if the keyword is used as a column name.
If it does cause a shift/reduce conflict, which is fairly likely for
anything that can appear inside an expression, you might still be
able to add the new keyword to the ColLabel: list. That allows it
to be used as an identifier in a more restricted set of contexts.
Only if neither of these will work does the keyword need to be a
truly "reserved" word.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-11-13 15:14:21 | Re: [HACKERS] Thread-safe queueing? |
Previous Message | Tom Lane | 1999-11-13 14:50:08 | Re: [HACKERS] Backend build fails in current |