Re: [HACKERS] [PATCHES] possible ecpg vpath build error
On Mon, Sep 04, 2006 at 12:06:02AM -0400, Tom Lane wrote: Michael Glaesemann [EMAIL PROTECTED] writes: There's a lot of duplicate code in ecpg. No kidding :-(. The parser is bad enough but the datatype library is an order of magnitude worse. I don't have a great solution at hand though. The backend utils/adt/ code gets to rely on the backend's Neither have I. error handling and memory management protocols, which I surely do not propose to remove, but how could we keep common sources when ecpglib has to work in a far less friendly environment? We could modify the backend code to use pgtypeslib, but that would cost at least a little bit of performance I would guess. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] possible ecpg vpath build error
Michael Meskes [EMAIL PROTECTED] writes: On Mon, Sep 04, 2006 at 12:06:02AM -0400, Tom Lane wrote: The backend utils/adt/ code gets to rely on the backend's error handling and memory management protocols, which I surely do not propose to remove, but how could we keep common sources when ecpglib has to work in a far less friendly environment? We could modify the backend code to use pgtypeslib, but that would cost at least a little bit of performance I would guess. I'd prefer to go in the other direction: provide enough infrastructure in ecpglib that it can use the unmodified backend sources. It would probably not take too much code to provide minimal elog and palloc support ... the question is what else would we need? (BTW, if anyone is working on making that pie-in-the-sky TODO list, here's a pet peeve for it: ecpg's bison parser should be auto-generated from the backend's, instead of derived manually.) regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] possible ecpg vpath build error
[Removing -patches] On Sep 4, 2006, at 10:33 , Tom Lane wrote: * AFAICT the ecpg regression tests are not affected by this change. Yeah, it doesn't look like there's any tests for interval at all. I suppose there should be. There's a lot of duplicate code in ecpg. Is there any way to pull that in from the main sections of the source code? Maybe the ecpg regression tests could run some relevant sections of the main regression tests as well? * You mentioned being unable to get the ecpg tests to run on your machine. I'm sure Michael and Joachim would like the details. The ecpg regression tests are pretty new and some portability problems are to be expected, but they seem to be passing on all the machines Michael and Joachim and I have access to. Good to hear. I'm using a script to handle my vpath builds, so I'll take a look at them later. There's a good chance the problem is with the script rather than the build itself. For the record, the error I'm getting is Makefile:3: ../../../src/Makefile.global: No such file or directory make: *** No rule to make target `../../../src/Makefile.global'. Stop. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] possible ecpg vpath build error
Michael Glaesemann [EMAIL PROTECTED] writes: There's a lot of duplicate code in ecpg. No kidding :-(. The parser is bad enough but the datatype library is an order of magnitude worse. I don't have a great solution at hand though. The backend utils/adt/ code gets to rely on the backend's error handling and memory management protocols, which I surely do not propose to remove, but how could we keep common sources when ecpglib has to work in a far less friendly environment? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] possible ecpg vpath build error
Michael Glaesemann [EMAIL PROTECTED] writes: For the record, the error I'm getting is Makefile:3: ../../../src/Makefile.global: No such file or directory make: *** No rule to make target `../../../src/Makefile.global'. Stop. From which Makefile exactly? Sounds like a pretty vanilla VPATH support bug, but can't chase it down with no context... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
