On 16.03.2012 14:50, Dimitri Fontaine wrote:
> Peter Eisentraut<peter_e@gmx.net> writes:
>>> Is there a reason for us not to add an HINT: "user" is a reserved
>>> keyword or something like that, other than nobody having been interested
>>> in doing the work?
>>
>> If that were easily possible, we could just recognize 'user' as an
>> identifier in this context and avoid the issue altogether. But it's
>> not.
>
> Thanks, I guess I see the logic here.
Accepting the keyword in such a context seems much harder to me than
providing a hint. To accept the keyword, you'd need a lot of changes to
the grammar, but for the hint, you just need some extra code in
yyerror(). Mind you, if it's a hint, it doesn't need to be 100%
accurate, so I think you could just always give the hint if you get a
grammar error at a token that's a reserved keyword.
Even if it was easy to accept the keywords when there's no ambiguity, I
don't think we would want that. Currently, we can extend the syntax
using existing keywords, knowing that we don't break existing
applications, but that would no longer be true if reserved keywords were
sometimes accepted as identifiers. For example, imagine that you had
this in your application:
CREATE TABLE foo (bar order);
"Order" is a reserved keyword so that doesn't work currently, but we
could accept it as an identifier in this context. But if we then decided
to extend the syntax, for example to allow "ORDER" as a synonym for
"serial" in CREATE TABLE clauses, that would stop working. We currently
avoid introducing new reserved keywords, because that can break existing
applications, but if we started to accept existing keywords as
identifiers in some contexts, we would have to be more careful with even
extending the use of existing keywords.
However, I like the idea of a hint, so +1 for Dimitri's original suggestion.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com