Обсуждение: 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
renamemy variable, but Andew and I were wondering if it's really necessary for "verbose" to be reserved, since it's not
inthe 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
thiserror: 
David> + psql:pgtap.sql:5789: ERROR:  syntax error at end of inputDavid> + LINE 28:                 IF verbose THEN
RETURNNEXT diag(tests[i] ||...David> +                                    ^ 
David> I asked on IRC, and Andrew “RhodiumToad” Gierth pointed outDavid> that it became a reserved word at some point.
I'mfine toDavid> rename my variable, but Andew and I were wondering if it'sDavid> really necessary for "verbose" to be
reserved,since it's notDavid> 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 systemEuler> view like say pg_keywords?

select * from pg_get_keywords();

-- 
Andrew (irc:RhodiumToad)