"value" a reserved word
I see we just recently made the word "value" reserved:
I noticed it because it breaks the contrib/tablefunc regression test. ISTM
like this will break quite a few applications.
Joe
Joe Conway <mail@joeconway.com> writes:
I see we just recently made the word "value" reserved:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/parser/keywords.c.diff?r1=1.130&r2=1.131
I noticed it because it breaks the contrib/tablefunc regression test. ISTM
like this will break quite a few applications.
I'm not thrilled about it either. I wonder whether we could hack up
something so that domain check constraints parse VALUE as a variable
name instead of a reserved keyword? Without some such technique I
think we're kinda stuck, because the spec is perfectly clear about
how to write domain check constraints.
(And, to be fair, SQL92 is also perfectly clear that VALUE is a reserved
word; people griping about this won't have a lot of ground to stand on.
But I agree it'd be worth trying to find an alternative implementation
that doesn't reserve the keyword.)
regards, tom lane
Tom Lane kirjutas L, 23.11.2002 kell 03:43:
Joe Conway <mail@joeconway.com> writes:
I see we just recently made the word "value" reserved:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/parser/keywords.c.diff?r1=1.130&r2=1.131
I noticed it because it breaks the contrib/tablefunc regression test. ISTM
like this will break quite a few applications.I'm not thrilled about it either. I wonder whether we could hack up
something so that domain check constraints parse VALUE as a variable
name instead of a reserved keyword? Without some such technique I
think we're kinda stuck, because the spec is perfectly clear about
how to write domain check constraints.(And, to be fair, SQL92 is also perfectly clear that VALUE is a reserved
word; people griping about this won't have a lot of ground to stand on.
But I agree it'd be worth trying to find an alternative implementation
that doesn't reserve the keyword.)
I've been playing around just a little in gram.y and I think that we are
paying too high price for keeping some keywords "somewhat reserved".
In light of trying to become fully ISO/ANSI compliant (or even savvy ;)
could we not make a jump at say 7.4 to having the same set of reserved
keywords as SQL92/SQL99 and be done with it?
There is an Estonian proverb about futility of "cutting off a dogs tail
in a small piece at a time" which seems to apply well to postgreSQL
syntax.
---------------
Hannu
Hannu Krosing <hannu@tm.ee> writes:
In light of trying to become fully ISO/ANSI compliant (or even savvy ;)
could we not make a jump at say 7.4 to having the same set of reserved
keywords as SQL92/SQL99 and be done with it?
I disagree ... especially for SQL99 keywords that we're not even using.
Also, SQL99 keywords that are actually only function names would be
outright more difficult to reserve than not to reserve...
regards, tom lane