Re: Perl 5.12 complains about ecpg parser-hacking scripts

From: Andy Colson <andy(at)squeakycode(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: kris(at)shannon(dot)id(dot)au, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Perl 5.12 complains about ecpg parser-hacking scripts
Date: 2011-01-23 17:08:34
Message-ID: 4D3C6092.3010503@squeakycode.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/23/2011 10:06 AM, Andrew Dunstan wrote:
>
>
> On 01/23/2011 10:16 AM, Andy Colson wrote:
>> On 01/23/2011 08:29 AM, Andy Colson wrote:
>>> On 01/22/2011 09:28 PM, kris(at)shannon(dot)id(dot)au wrote:
>>>> On 23 January 2011 13:14, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>>>>> But there are quite a few perlheads around. ISTR Matt Trout was muttering
>>>>> about these scripts on IRC recently.
>>
>> Ok, so I've figured out what its purpose is.
>>
>> Are there other problems with this script? Does it not pull out the rule names correct all the time or something? What problem was Matt having with it?
>>
>> I think rewriting from scratch is overkill, unless this script is just failing. The code to pull the rule names out is a bit complex, and it seems to work, so I'd rather not touch it.
>>
>> Are there other things you wished this script did? (reports, counts, etc)
>>
>>
>
>
> 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

** OOPS, forenote: I only noticed check_rules.pl. That's the only file I looked at. I'll go look at parse.pl right now. Below refers to check_rules.pl only.

I can comment the code. $[ can safely be removed (from check_rules.pl) because we are not even using arrays.

I disagree (check_rules.pl) is not spaghetti code. There are two loops, one thru gram.y to pick out the rule names, and one through ecpg.addons to make sure they are in use.

Unmaintainable is another story. Parsing gram.y for rule names, then combining them to make up the same name in ecpg.addons is a little complex. But then I think it would be a little complex in any language. A little change to the syntax/layout of either file and it could go bad, but you'd have that same problem with any other language too.

Is there anyway to make bison/yacc/gcc/etc spit out the rule names?

I'm not sure rule name is the proper words. In gram.y we have:

stmt :
AlterDatabaseStmt
| AlterDatabaseSetStmt

We pull out and create:

stmtAlterDatabaseStmt
and
stmtAlterDatabaseSetStmt

-Andy

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-01-23 17:12:15 Re: sepgsql contrib module
Previous Message Tom Lane 2011-01-23 17:06:43 Re: ALTER TYPE 2: skip already-provable no-work rewrites