Обсуждение: "value" a reserved word

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.

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

Joe Conway <mail@joeconway.com> writes:
> I see we just recently made the word "value" reserved:

FYI, it's not reserved any more.
        regards, tom lane