Re: [HACKERS] "value" a reserved word
Joe Conway <[EMAIL PROTECTED]> writes: > I see we just recently made the word "value" reserved: FYI, it's not reserved any more. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] "value" a reserved word
Hannu Krosing <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] "value" a reserved word
Tom Lane kirjutas L, 23.11.2002 kell 03:43: > Joe Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] "value" a reserved word
Joe Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] "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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]