Thread: Syntax error and reserved keywords
Hi, A colleague came to me to express his surprise about this quite simple use case: =# alter table toto add column user text; ERROR: syntax error at or near "user" LINE 1: alter table toto add column usertext; 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? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
2012/3/14 Dimitri Fontaine <dimitri@2ndquadrant.fr>: > Hi, > > A colleague came to me to express his surprise about this quite simple > use case: > > =# alter table toto add column user text; > ERROR: syntax error at or near "user" > LINE 1: alter table toto add column user text; > > 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? Probably nobody did this work. I am thinking so on current code, this request is relatively simple implemented - and I agree so this can be really nice feature. Regards Pavel > > Regards, > -- > Dimitri Fontaine > http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
On 14-03-2012 10:58, Dimitri Fontaine wrote: > 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? > AFAIK, there is no such warning message in the code. If you're volunteering to do it, please cover all sql commands. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte24x7 e Treinamento
2012/3/14 Pavel Stehule <pavel.stehule@gmail.com>: > 2012/3/14 Dimitri Fontaine <dimitri@2ndquadrant.fr>: >> Hi, >> >> A colleague came to me to express his surprise about this quite simple >> use case: >> >> =# alter table toto add column user text; >> ERROR: syntax error at or near "user" >> LINE 1: alter table toto add column user text; >> >> 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? > > Probably nobody did this work. I am thinking so on current code, this > request is relatively simple implemented - and I agree so this can be > really nice feature. > but it is not too simple as I though this message coming from scanner_yyerror - and forwarding hint into this "callback" routine is not trivial - more - this message is used when word is reserved keyword and must not be and when word is just wrong reserved keyword. Regards Pavel > Regards > > Pavel > >> >> Regards, >> -- >> Dimitri Fontaine >> http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers
On ons, 2012-03-14 at 14:58 +0100, Dimitri Fontaine wrote: > A colleague came to me to express his surprise about this quite simple > use case: > > =# alter table toto add column user text; > ERROR: syntax error at or near "user" > LINE 1: alter table toto add column user text; > > 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.
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. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
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
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> 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.
Unfortunately, while a useful hint doesn't have to be 100% right, it
does have to be a great deal more than 0% right. And what you're
suggesting here would be nearly all noise. For example, if I writeSELECT ORDER BY x;
it is not going to be helpful to be told that ORDER is a reserved word.
It will soon become annoying for that hint to pop up in many contexts
where it's completely inappropriate.
If you could restrict it to only happen in contexts where the *only*
expected token is an identifier, it might be of some use, but I'm
doubtful that yyerror() has that much info.
There is some stuff in the Bison manual about writing "error"
productions, which I've never paid much attention to because it only
seemed to be useful for resychronizing between statements. But maybe
there's something there for this purpose.
> 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.
Good point.
regards, tom lane