Re: Perl 5.12 complains about ecpg parser-hacking scripts - Mailing list pgsql-hackers

From kris@shannon.id.au
Subject Re: Perl 5.12 complains about ecpg parser-hacking scripts
Date
Msg-id AANLkTikRx5STPNkeKTAAyNh1zHEZ_p5knWStkQisRzpH@mail.gmail.com
Whole thread Raw
In response to Re: Perl 5.12 complains about ecpg parser-hacking scripts  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On 24 January 2011 03:06, Andrew Dunstan <andrew@dunslane.net> wrote:
> It's doing the right thing. But it's really spaghetti code, generated by
> a2p. Matt was just (rightly) offended by the $[ setting, IIRC.
>
> The point is that it's close to being totally unmaintainable.
>
> But if you think you can remedy it without rewriting it, go for it.
>
> I think minimum requirements would be:
>
>   * avoid setting $[
>   * use strict;
>   * comments saying what it's actually doing
>
>
> We want to be in a situation where of it ever does break because of some
> external change, we're not left having to wade through the crap to find out
> how to fix it.
>
> cheers
>
> andrew
>

Well here's an absolutely minimal patch to remove the $[ assignments
and fix up the array accesses.
I have tested that parse.pl produces identical output for both HEAD
and the 65 commits which touch ecpg.*
or gram.y since the introduction on check_rules.pl

git log 81a82a13^..HEAD -- src/backend/parser/gram.y
src/interfaces/ecpg/preproc/{ecpg.??*,*.pl}

I've also tested that the new check_rules.pl dies when I add an extra
unused rule to ecpg.addons.

I'll try and make a proper rewrite sometime this week.

What is the minimal perl version that we are requiring these days?

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Perl 5.12 complains about ecpg parser-hacking scripts
Next
From: kris@shannon.id.au
Date:
Subject: Re: Perl 5.12 complains about ecpg parser-hacking scripts