Does "verbose" Need to be Reserved?
Hey All,
I was just getting a new version of pgTAP ready for release, and while testing it on HEAD, I got this error:
+ psql:pgtap.sql:5789: ERROR: syntax error at end of input
+ LINE 28: IF verbose THEN RETURN NEXT diag(tests[i] ||...
+ ^
I asked on IRC, and Andrew “RhodiumToad” Gierth pointed out that it became a reserved word at some point. I'm fine to rename my variable, but Andew and I were wondering if it's really necessary for "verbose" to be reserved, since it's not in the spec.
Thanks,
David
"David" == "David E Wheeler" <david@kineticode.com> writes:
David> Hey All,
David> I was just getting a new version of pgTAP ready for release, and while testing it on HEAD, I got this error:
David> + psql:pgtap.sql:5789: ERROR: syntax error at end of input
David> + LINE 28: IF verbose THEN RETURN NEXT diag(tests[i] ||...
David> + ^
David> I asked on IRC, and Andrew “RhodiumToad” Gierth pointed out
David> that it became a reserved word at some point. I'm fine to
David> rename my variable, but Andew and I were wondering if it's
David> really necessary for "verbose" to be reserved, since it's not
David> in the spec.
Looking at it more closely, this is likely to be fallout from the
plpgsql lexer/parser changes; it probably worked before only because
plpgsql was doing its own thing rather than using the main lexer.
VERBOSE has been reserved all along in order to distinguish
'vacuum verbose;' from 'vacuum tablename;' and so on; but it's still an
interesting pitfall for plpgsql users.
--
Andrew (irc:RhodiumToad)
"David E. Wheeler" <david@kineticode.com> writes:
I asked on IRC, and Andrew �RhodiumToad� Gierth pointed out that
it became a reserved word at some point.
"Some point" would have been around the time VACUUM VERBOSE got
invented, ie January 1997 according to the CVS logs. We can't unreserve
it until you're ready to break that syntax (is VERBOSE a table name
or a flag for a database-wide vacuum?). Don't hold your breath.
regards, tom lane
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
Looking at it more closely, this is likely to be fallout from the
plpgsql lexer/parser changes; it probably worked before only because
plpgsql was doing its own thing rather than using the main lexer.
Hmm .. yeah, words that are reserved according to the main grammar
could have worked as plpgsql variable names before, since they always
got replaced with "$n" before the main grammar saw them.
regards, tom lane
On Dec 16, 2009, at 2:29 PM, Tom Lane wrote:
Looking at it more closely, this is likely to be fallout from the
plpgsql lexer/parser changes; it probably worked before only because
plpgsql was doing its own thing rather than using the main lexer.Hmm .. yeah, words that are reserved according to the main grammar
could have worked as plpgsql variable names before, since they always
got replaced with "$n" before the main grammar saw them.
A list of such words, to be included in the Changes file, would be most useful I expect.
Best,
David
David E. Wheeler escreveu:
A list of such words, to be included in the Changes file, would be most useful I expect.
As we're on this topic, could we expose keywords in a system view like say
pg_keywords?
--
Euler Taveira de Oliveira
http://www.timbira.com/
"Euler" == Euler Taveira de Oliveira <euler@timbira.com> writes:
David E. Wheeler escreveu:
A list of such words, to be included in the Changes file, would be
most useful I expect.
I'm guessing "Keywords listed as reserved in appendix C no longer work as
variable names in pl/pgsql, even though they might have worked in previous
versions" just about covers it.
Euler> As we're on this topic, could we expose keywords in a system
Euler> view like say pg_keywords?
select * from pg_get_keywords();
--
Andrew (irc:RhodiumToad)