Re: [COMMITTERS] pgsql: Add new keywords SNAPSHOT and TYPES to the keyword list in gram.

Add new keywords SNAPSHOT and TYPES to the keyword list in gram.y

These were added to kwlist.h as unreserved keywords in separate patches,
but authors forgot to add them to the corresponding list in gram.y.
Because of that, even though they were supposed to be unreserved keywords,
they could not be used as identifiers. src/tools/check_keywords.pl is your
friend.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/82e73ba0d1f8990a76a20b3a57957e633945fb2b

Modified Files
--------------
src/backend/parser/gram.y | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

Excerpts from Heikki Linnakangas's message of jue feb 09 06:42:12 -0300 2012:
> Add new keywords SNAPSHOT and TYPES to the keyword list in gram.y
>
> These were added to kwlist.h as unreserved keywords in separate patches,
> but authors forgot to add them to the corresponding list in gram.y.
> Because of that, even though they were supposed to be unreserved keywords,
> they could not be used as identifiers. src/tools/check_keywords.pl is your
> friend.

I wondered a couple of weeks ago if we could, instead, generate the
lists in gram.y from kwlist.h.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Heikki Linnakangas's message of jue feb 09 06:42:12 -0300 2012:
>> src/tools/check_keywords.pl is your friend.

> I wondered a couple of weeks ago if we could, instead, generate the
> lists in gram.y from kwlist.h.

We've looked into that in the past. bison does not seem to have any
sort of "include" directive, which means the only way to do it would be
to have the gram.y file be built from pieces at compile time. Although
Michael is successfully doing something of the sort for ecpg, I find it
way too ugly in return for the amount of benefit we'd get.

If people are sufficiently worried about this, a better answer would be
to teach the makefiles to run check_keywords.pl during every build.

regards, tom lane

Excerpts from Tom Lane's message of jue feb 09 12:17:59 -0300 2012:
>
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Excerpts from Heikki Linnakangas's message of jue feb 09 06:42:12 -0300 2012:
> >> src/tools/check_keywords.pl is your friend.
>
> > I wondered a couple of weeks ago if we could, instead, generate the
> > lists in gram.y from kwlist.h.
>
> We've looked into that in the past. bison does not seem to have any
> sort of "include" directive, which means the only way to do it would be
> to have the gram.y file be built from pieces at compile time.

Doh, bummer.

> Although
> Michael is successfully doing something of the sort for ecpg, I find it
> way too ugly in return for the amount of benefit we'd get.

Agreed.

> If people are sufficiently worried about this, a better answer would be
> to teach the makefiles to run check_keywords.pl during every build.

FWIW that script is throwing a warning here:
Use of assignment to $[ is deprecated at /pgsql/source/HEAD/src/tools/check_keywords.pl line 19.

Also, we should at least do the attached to simplify the process.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of jue feb 09 12:17:59 -0300 2012:
>> If people are sufficiently worried about this, a better answer would be
>> to teach the makefiles to run check_keywords.pl during every build.

> FWIW that script is throwing a warning here:
> Use of assignment to $[ is deprecated at /pgsql/source/HEAD/src/tools/check_keywords.pl line 19.

Any Perl hackers want to improve that script?

> Also, we should at least do the attached to simplify the process.
> +check:
> + $(top_srcdir)/src/tools/check_keywords.pl $(top_srcdir)

Actually, what would make sense in that line is to attach it to the
existing maintainer-check target, no? I don't think top-level
"make check" descends into this directory.

regards, tom lane

On Thu, Feb 9, 2012 at 11:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Excerpts from Tom Lane's message of jue feb 09 12:17:59 -0300 2012:

>> FWIW that script is throwing a warning here:
>> Use of assignment to $[ is deprecated at /pgsql/source/HEAD/src/tools/check_keywords.pl line 19.
>
> Any Perl hackers want to improve that script?

The attached 2 liner does it for me.

On 11.02.2012 11:57, Alex Hunsaker wrote:
> On Thu, Feb 9, 2012 at 11:30, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alvaro Herrera<alvherre(at)commandprompt(dot)com> writes:
>>> Excerpts from Tom Lane's message of jue feb 09 12:17:59 -0300 2012:
>
>>> FWIW that script is throwing a warning here:
>>> Use of assignment to $[ is deprecated at /pgsql/source/HEAD/src/tools/check_keywords.pl line 19.
>>
>> Any Perl hackers want to improve that script?
>
> The attached 2 liner does it for me.

Thanks, applied!

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On tor, 2012-02-09 at 13:30 -0500, Tom Lane wrote:
> > Also, we should at least do the attached to simplify the process.
> > +check:
> > + $(top_srcdir)/src/tools/check_keywords.pl $(top_srcdir)
>
> Actually, what would make sense in that line is to attach it to the
> existing maintainer-check target, no? I don't think top-level
> "make check" descends into this directory.

I have hooked this into maintainer-check now.