Обсуждение: gram.y=>preproc.y
The attached version now is able to generate an ecpg parser without a single change in gram.y. Also included is a perl version of the script created by a2p and fixed by me. Unfortunately a2p did not generate working code, so I guess eventually we have to only work with the perl version. I guess a perl hacker can beautify the script quite a bit. Anyway, it does work, regression tests run through (need to update expected results though). So guys, now's the time to test before it makes it into the archive. :-) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Вложения
Michael Meskes <meskes@postgresql.org> writes:
> The attached version now is able to generate an ecpg parser without a single
> change in gram.y.
Sweet.
> Also included is a perl version of the script created by a2p
> and fixed by me. Unfortunately a2p did not generate working code, so I guess
> eventually we have to only work with the perl version. I guess a perl hacker
> can beautify the script quite a bit.
We should probably standardize on the perl version, ugly or not, because
otherwise we'll have a difference in build process between Unix and
Windows machines. Personally I don't really care how ugly it is as long
as no one has to look at it ;-) ... but if someone wants to beautify the
perl script they're surely welcome to do so.
A few notes:
* before committing we need to see the proposed diffs to the Makefiles
and the Windows build scripts.
* As-is, the first few lines of parse.pl contain an unportable hardwired
assumption about where the perl executable is. I'd suggest removing
those lines and having the makefile call the script as
$(PERL) parse.pl ...
* Can we get a $PostgreSQL$ version identifier into each file that
will be added to CVS?
regards, tom lane
On Nov 10, 2008, at 8:03 AM, Tom Lane wrote: > We should probably standardize on the perl version, ugly or not, > because > otherwise we'll have a difference in build process between Unix and > Windows machines. Personally I don't really care how ugly it is as > long > as no one has to look at it ;-) ... but if someone wants to beautify > the > perl script they're surely welcome to do so. I'd be happy to, but I haven't really been following this thread. What does it do, and how do I make sure it continues to work as I refactor it? I'm fine to wait until it's committed, too. > Best, David
David E. Wheeler wrote: > On Nov 10, 2008, at 8:03 AM, Tom Lane wrote: > >> We should probably standardize on the perl version, ugly or not, because >> otherwise we'll have a difference in build process between Unix and >> Windows machines. Personally I don't really care how ugly it is as long >> as no one has to look at it ;-) ... but if someone wants to beautify the >> perl script they're surely welcome to do so. > > I'd be happy to, but I haven't really been following this thread. What > does it do, and how do I make sure it continues to work as I refactor it? > > I'm fine to wait until it's committed, too. > > I have had a quick look at it. The perl is more than ugly - it's unmaintainable IMNSHO. It violates perl best practice in many ways, and reflects the age of the a2p utility quite badly. There is no guarantee that the script won't have to be looked at. Rather, the reverse is our experience, so this is a real consideration. I agree that a perl version is much more desirable, but it really requires a hand translation from awk rather than a hacked a2p output. David, how is your awk-fu? If it's any good then I'm happy to leave it to you. Otherwise I will try to make a few hours somewhere to un-uglify this. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> I have had a quick look at it. The perl is more than ugly - it's
> unmaintainable IMNSHO. It violates perl best practice in many ways, and
> reflects the age of the a2p utility quite badly.
> There is no guarantee that the script won't have to be looked at.
> Rather, the reverse is our experience, so this is a real consideration.
> I agree that a perl version is much more desirable, but it really
> requires a hand translation from awk rather than a hacked a2p output.
IMHO awk was the wrong language to begin with, so I'd vote for a fresh
implementation with re-thought data structures rather than just cleaning
up around the edges. However, I would like any reimplementation to
happen after we get this in, not before. As long as we are agreed that
a perl script is the appropriate tool, someone can go off in a corner
and reimplement without holding up anything else. And it's surely past
time that Michael stops having to sync ecpg with the main grammar by
hand.
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> I have had a quick look at it. The perl is more than ugly - it's >> unmaintainable IMNSHO. It violates perl best practice in many ways, and >> reflects the age of the a2p utility quite badly. >> > > >> There is no guarantee that the script won't have to be looked at. >> Rather, the reverse is our experience, so this is a real consideration. >> > > >> I agree that a perl version is much more desirable, but it really >> requires a hand translation from awk rather than a hacked a2p output. >> > > IMHO awk was the wrong language to begin with, so I'd vote for a fresh > implementation with re-thought data structures rather than just cleaning > up around the edges. That was what I was intending. The awk would just be a guide as to the required logic. > However, I would like any reimplementation to > happen after we get this in, not before. As long as we are agreed that > a perl script is the appropriate tool, someone can go off in a corner > and reimplement without holding up anything else. And it's surely past > time that Michael stops having to sync ecpg with the main grammar by > hand. > > > Sure. No argument at all from me. cheers andrew
Tom Lane wrote: > Michael Meskes <meskes@postgresql.org> writes: >> Also included is a perl version of the script created by a2p >> and fixed by me. Unfortunately a2p did not generate working code, so I guess >> eventually we have to only work with the perl version. I guess a perl hacker >> can beautify the script quite a bit. > > We should probably standardize on the perl version, ugly or not, because > otherwise we'll have a difference in build process between Unix and > Windows machines. Personally I don't really care how ugly it is as long > as no one has to look at it ;-) ... but if someone wants to beautify the > perl script they're surely welcome to do so. +1. > A few notes: > > * before committing we need to see the proposed diffs to the Makefiles > and the Windows build scripts. It might be worthwhile to make it as a perl module, called from the commandline in Unix and just included directly in the win32 build scripts. But someone more perly can comment on if that's a prettier way or not:-) //Magnus
On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote: > David, how is your awk-fu? If it's any good then I'm happy to leave > it to you. Otherwise I will try to make a few hours somewhere to un- > uglify this. My Perl is excellent, but my awk is remedial. What part does awk play? Best, David
David E. Wheeler wrote: > On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote: > >> David, how is your awk-fu? If it's any good then I'm happy to leave >> it to you. Otherwise I will try to make a few hours somewhere to >> un-uglify this. > > My Perl is excellent, but my awk is remedial. What part does awk play? > > I know about your perl ;-) The original is in awk. It's the a2p translation to Perl that's horrid. It's OK - I'll do it before long. cheers andrew
Andrew Dunstan wrote: > > > David E. Wheeler wrote: > > On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote: > > > >> David, how is your awk-fu? If it's any good then I'm happy to leave > >> it to you. Otherwise I will try to make a few hours somewhere to > >> un-uglify this. > > > > My Perl is excellent, but my awk is remedial. What part does awk play? > > > > > > I know about your perl ;-) > > The original is in awk. It's the a2p translation to Perl that's horrid. > > It's OK - I'll do it before long. I know awk well and perl mediocre so I can help. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Mon, Nov 10, 2008 at 11:03:37AM -0500, Tom Lane wrote: > * before committing we need to see the proposed diffs to the Makefiles > and the Windows build scripts. Sure. I just committed the generated preproc.y file to see how it goes through the buildfarm. I prefer to see the file is okay everywhere, before automating things. > * As-is, the first few lines of parse.pl contain an unportable hardwired > assumption about where the perl executable is. I'd suggest removing > ... Sure, this is just how a2p creates it. > * Can we get a $PostgreSQL$ version identifier into each file that > will be added to CVS? Definitely. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
On Mon, Nov 10, 2008 at 09:38:58AM -0800, David E. Wheeler wrote: > I'd be happy to, but I haven't really been following this thread. What > does it do, and how do I make sure it continues to work as I refactor > it? Just run parse.pl < pgsql/src/backend/parser/gram.y > preproc.y and compare the result to pgsql/src/interfaces/ecpg/preproc/preproc.y. Both files should be identical. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!