Re: [HACKERS] gram.y = preproc.y
On Thu, Nov 13, 2008 at 03:57:49PM -0500, Tom Lane wrote: Michael Meskes [EMAIL PROTECTED] writes: That's what I did first, but Magnus had a good reasoning to not keep preproc.y if we keep preproc.c in our tarball. And I agreed that there doesn't seem to be an advantage. Other than whether it *works*, you mean? make will not be happy if it has a dependency from preproc.c to preproc.y and preproc.y is not there. Please don't mess with this. It doesn't complain but rebuild preproc.y which makes no sense at all. Removed preproc.y from make clean. 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: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
On Thu, Nov 13, 2008 at 03:10:04PM -0500, Tom Lane wrote:
VPATH build. (Parts of this patch have that right and part don't.
You might want to test in a VPATH build before committing.)
Did that and fixed the remaining problems. Attached you'll find the latest
version. I already committed the new files, so the patch is way smaller.
However, the new files are not used without the attached changes to the build
system.
Does anyone see a problem with these changes? Or else I will commit.
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: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
diff --exclude CVS -ruN pgsql/src/interfaces/ecpg/preproc/Makefile pgsql/src.mm/interfaces/ecpg/preproc/Makefile
--- pgsql/src/interfaces/ecpg/preproc/Makefile 2008-11-14 11:01:55.0 +0100
+++ pgsql/src.mm/interfaces/ecpg/preproc/Makefile 2008-11-14 10:59:44.0 +0100
@@ -52,6 +52,9 @@
@$(missing) flex $ $@
endif
+$(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y
+ $(PERL) $(srcdir)/parse.pl $(srcdir) $ $@
+
ecpg_keywords.o c_keywords.o keywords.o preproc.o parser.o: preproc.h
# instead of maintaining our own list, take the one from the backend
diff --exclude CVS -ruN pgsql/src/tools/msvc/Solution.pm pgsql/src.mm/tools/msvc/Solution.pm
--- pgsql/src/tools/msvc/Solution.pm 2008-08-17 09:09:16.0 +0200
+++ pgsql/src.mm/tools/msvc/Solution.pm 2008-11-13 15:15:50.0 +0100
@@ -239,6 +239,19 @@
if (
IsNewer(
+'src\interfaces\ecpg\preproc\preproc.y',
+'src\backend\parser\gram.y'
+)
+ )
+{
+print Generating preproc.y...\n;
+chdir('src\interfaces\ecpg\preproc');
+system('perl parse.pl . ..\..\..\backend\parser\gram.y preproc.y');
+chdir('..\..\..\..');
+}
+
+if (
+IsNewer(
'src\interfaces\ecpg\include\ecpg_config.h',
'src\interfaces\ecpg\include\ecpg_config.h.in'
)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
Michael Meskes wrote: +$(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y + $(PERL) $(srcdir)/parse.pl $(srcdir) $ $@ Why are you passing $(srcdir) as a parameter here? It doesn't look like the script uses it at all, or does it? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
On Fri, Nov 14, 2008 at 09:03:34AM -0300, Alvaro Herrera wrote: +$(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y + $(PERL) $(srcdir)/parse.pl $(srcdir) $ $@ Why are you passing $(srcdir) as a parameter here? It doesn't look like the script uses it at all, or does it? The new version does. I need to tell the script where to find the other files in a VPATH build system. 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: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
Michael Meskes [EMAIL PROTECTED] writes: Does anyone see a problem with these changes? Or else I will commit. preproc.y should be removed by make maintainer-clean. For consistency it probably ought to be listed in the distprep target too, even though it would be indirectly updated by the preproc.c target. I suspect it would be a good idea to list preproc.c's antecedent as $(srcdir)/preproc.y not just preproc.y. Also, you'll need to add preproc.y to .cvsignore. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
Michael Meskes wrote: Does anyone see a problem with these changes? Or else I will commit. FWIW, I have looked at this a bit. I want to refactor it at some stage because it's ugly and fragile and rather obtuse, but the refactoring won't be happening for a while. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
On Fri, Nov 14, 2008 at 10:44:08AM -0500, Tom Lane wrote:
preproc.y should be removed by make maintainer-clean. For consistency
it probably ought to be listed in the distprep target too, even though
it would be indirectly updated by the preproc.c target. I suspect it
would be a good idea to list preproc.c's antecedent as
$(srcdir)/preproc.y not just preproc.y. Also, you'll need to add
preproc.y to .cvsignore.
Added.
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: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
diff --exclude CVS -ruN pgsql/src/interfaces/ecpg/preproc/.cvsignore pgsql/src.mm/interfaces/ecpg/preproc/.cvsignore
--- pgsql/src/interfaces/ecpg/preproc/.cvsignore 2008-05-20 17:41:12.0 +0200
+++ pgsql/src.mm/interfaces/ecpg/preproc/.cvsignore 2008-11-14 17:35:09.0 +0100
@@ -1,3 +1,4 @@
+preproc.y
preproc.c
preproc.h
pgc.c
diff --exclude CVS -ruN pgsql/src/interfaces/ecpg/preproc/Makefile pgsql/src.mm/interfaces/ecpg/preproc/Makefile
--- pgsql/src/interfaces/ecpg/preproc/Makefile 2008-11-14 11:01:55.0 +0100
+++ pgsql/src.mm/interfaces/ecpg/preproc/Makefile 2008-11-14 17:34:38.0 +0100
@@ -38,27 +38,30 @@
$(srcdir)/preproc.h: $(srcdir)/preproc.c ;
-$(srcdir)/preproc.c: preproc.y
+$(srcdir)/preproc.c: $(srcdir)/preproc.y
ifdef BISON
$(BISON) -d $(BISONFLAGS) -o $@ $
else
@$(missing) bison $ $@
endif
-$(srcdir)/pgc.c: pgc.l
+$(srcdir)/pgc.c: $(srcdir)/pgc.l
ifdef FLEX
$(FLEX) $(FLEXFLAGS) -o'$@' $
else
@$(missing) flex $ $@
endif
+$(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y
+ $(PERL) $(srcdir)/parse.pl $(srcdir) $ $@
+
ecpg_keywords.o c_keywords.o keywords.o preproc.o parser.o: preproc.h
# instead of maintaining our own list, take the one from the backend
keywords.c: % : $(top_srcdir)/src/backend/parser/%
rm -f $@ $(LN_S) $ .
-distprep: $(srcdir)/preproc.c $(srcdir)/preproc.h $(srcdir)/pgc.c
+distprep: $(srcdir)/preproc.y $(srcdir)/preproc.c $(srcdir)/preproc.h $(srcdir)/pgc.c
install: all installdirs
$(INSTALL_PROGRAM) ecpg$(X) '$(DESTDIR)$(bindir)'
@@ -78,4 +81,4 @@
# want to ship those files in the distribution for people with
# inadequate tools.
maintainer-clean: distclean
- rm -f $(srcdir)/preproc.c $(srcdir)/preproc.h $(srcdir)/pgc.c
+ rm -f $(srcdir)/preproc.y $(srcdir)/preproc.c $(srcdir)/preproc.h $(srcdir)/pgc.c
diff --exclude CVS -ruN pgsql/src/tools/msvc/Solution.pm pgsql/src.mm/tools/msvc/Solution.pm
--- pgsql/src/tools/msvc/Solution.pm 2008-08-17 09:09:16.0 +0200
+++ pgsql/src.mm/tools/msvc/Solution.pm 2008-11-13 15:15:50.0 +0100
@@ -239,6 +239,19 @@
if (
IsNewer(
+'src\interfaces\ecpg\preproc\preproc.y',
+'src\backend\parser\gram.y'
+)
+ )
+{
+print Generating preproc.y...\n;
+chdir('src\interfaces\ecpg\preproc');
+system('perl parse.pl ..\..\..\backend\parser\gram.y preproc.y');
+chdir('..\..\..\..');
+}
+
+if (
+IsNewer(
'src\interfaces\ecpg\include\ecpg_config.h',
'src\interfaces\ecpg\include\ecpg_config.h.in'
)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
Michael Meskes [EMAIL PROTECTED] writes: Added. Looks alright to me now --- you might as well commit and let the buildfarm find any remaining problems. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
Michael Meskes [EMAIL PROTECTED] writes: since my last email seems to have disappeared, here we go again. Here's my current patch that includes the changes to the build system. Thanks to Magnus for the Windows part. Comments anyone? + $(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y + perl parse.pl $ $@ Use $(PERL) here. (I'm not sure about the equivalent in the Windows world; it looks like there are already places in Solution.pm that invoke perl via just system(perl ...), but is that really a good idea? Anyway, not directly your problem.) clean distclean: ! rm -f keywords.c *.o ecpg$(X) preproc.y Actually, we want to fix it so that preproc.y is treated like preproc.c, ie, it's part of the shipped tarballs even though it's no longer in CVS. For the same reason, you want to generate it in $(srcdir) even in a VPATH build. (Parts of this patch have that right and part don't. You might want to test in a VPATH build before committing.) Can't comment on the MSVC change. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
Michael Meskes [EMAIL PROTECTED] writes: That's what I did first, but Magnus had a good reasoning to not keep preproc.y if we keep preproc.c in our tarball. And I agreed that there doesn't seem to be an advantage. Other than whether it *works*, you mean? make will not be happy if it has a dependency from preproc.c to preproc.y and preproc.y is not there. Please don't mess with this. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
On Thu, Nov 13, 2008 at 03:10:04PM -0500, Tom Lane wrote: clean distclean: ! rm -f keywords.c *.o ecpg$(X) preproc.y Actually, we want to fix it so that preproc.y is treated like preproc.c, ie, it's part of the shipped tarballs even though it's no longer in CVS. That's what I did first, but Magnus had a good reasoning to not keep preproc.y if we keep preproc.c in our tarball. And I agreed that there doesn't seem to be an advantage. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
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: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
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: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
Michael Meskes [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
Andrew Dunstan [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
Tom Lane wrote: Michael Meskes [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y
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 [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y=preproc.y II
Michael Meskes [EMAIL PROTECTED] writes: ... What still needs to be done is beautifying the script (I don't like all those static declarations) and removing the remaining changes to gram.y. There are only two left (variable handling on quite some places and prepared_name twice). Adding a new production prepared_name for names of prepared statements doesn't bother me, if you have a need for that. But please get rid of those renamings of Sconst and Iconst ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
On Tue, Nov 04, 2008 at 01:03:44PM -0500, Tom Lane wrote: I'm quite unhappy with the invasiveness of the proposed gram.y changes. Keep in mind that this is work in progress. I'm still working on this stuff and yes, I'm trying to simplify things. The @ECPG annotations are bad enough, but why are you changing actual productions? I'm not entirely convinced that the backend still parses exactly what it did before. There are essantially two changes (unless I forgot about a third one :-)): - fetch_count: I can remove that one easily by including the block on every single production for fetch. Doesn't look like a problem. This change came from me taking some stuff from preproc.y to get a working version first before simplifying. - variable handling: This creates the most changes. ECPG needs to accept variables at quite some places where the backend only accepts constants. The easy way (again WIP) is to add a variable production to each constant rule. However, this obviously creates conflicts when allowinf Sconst and Iconst for the same non-terminal. Therefore I added new non-terminals SconstVar and IconstVar that just resolve to Sconst and Iconst in gram.y. If you have a better idea I'm willing to listen. It strikes me that most if not all of the @ECPGINCLUDE annotations ought to be unnecessary given that you've carefully identified each chunk of ecpg.addons. The substitution script ought to be able to match those annotations to the input for itself. You mean by hard coding the position? Hmm, that's possibly but creates just another situation where we might need a manual sync. Just take an addition that's supposed to be added to the second rule for a non-terminal. Now if you insert something before that second rule, it won't work anymore. FWIW, I'm also pretty firmly convinced that awk was the wrong choice for implementing this script... Well, I work with what I have. What language would you prefer? And btw what makes you so convinced? 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: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
Michael Meskes [EMAIL PROTECTED] writes: On Mon, Nov 03, 2008 at 07:10:01PM -0500, Tom Lane wrote: (You might need to compress the files if the message comes to more than 100-some KB. Also, given that preproc.y can be generated so easily, it could just be left out.) I did this this time. The file is just 84K. Came through this time, thanks. I'm quite unhappy with the invasiveness of the proposed gram.y changes. The @ECPG annotations are bad enough, but why are you changing actual productions? I'm not entirely convinced that the backend still parses exactly what it did before. It strikes me that most if not all of the @ECPGINCLUDE annotations ought to be unnecessary given that you've carefully identified each chunk of ecpg.addons. The substitution script ought to be able to match those annotations to the input for itself. FWIW, I'm also pretty firmly convinced that awk was the wrong choice for implementing this script... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gram.y = preproc.y
Michael Meskes [EMAIL PROTECTED] writes: I finally have a working version. Please have a look at the attached files including a changed version of gram.y and and automatically created version of preproc.y. To recreate just run awk -f parse.awk gram.y preproc.y. Ping? I've been expecting a followup that actually has the attachments ... (You might need to compress the files if the message comes to more than 100-some KB. Also, given that preproc.y can be generated so easily, it could just be left out.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
