Re: Syntax error and reserved keywords
Re: Syntax error and reserved keywords
От:
Peter Eisentraut <peter_e@gmx.net>
Дата:
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.
Re: Syntax error and reserved keywords
От:
Euler Taveira <euler@timbira.com>
Дата:
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, Suporte 24x7 e Treinamento
Re: Syntax error and reserved keywords
От:
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Дата:
On 16.03.2012 14:50, Dimitri Fontaine wrote: > Peter Eisentraut 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
Re: Syntax error and reserved keywords
От:
Tom Lane <tgl@sss.pgh.pa.us>
Дата:
Heikki Linnakangas 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
Syntax error and reserved keywords
От:
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? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Re: Syntax error and reserved keywords
От:
Pavel Stehule <pavel.stehule@gmail.com>
Дата:
2012/3/14 Dimitri Fontaine : > 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
Re: Syntax error and reserved keywords
От:
Pavel Stehule <pavel.stehule@gmail.com>
Дата:
2012/3/14 Pavel Stehule : > 2012/3/14 Dimitri Fontaine : >> 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
Re: Syntax error and reserved keywords
От:
Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Дата:
Peter Eisentraut 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
