Thread: ECPG
Hi, I just removed the prepare/execute/deallocate function from ecpg's parser so there are no conflicts anymore. But for the future (that is after 7.3 is released) I'd like to work something out. The only problem I see with using the backend functions is that the backend prepare needs the data type for each variable and I have no idea how to present it given the embedded syntax. I take it the backend prepare cannot work without this info, can it? Also I still have some open bug reports but on the other hand few to no available time. Shall we add these reports to the TODO list? I doubt I'll be able to fix them ntil release time, at least not all of them. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
I had a thought about what to do with the ECPG grammar-too-big problem:
rather than depending on a beta release of bison, we could attack the
problem directly by omitting some of the backend grammar from what ECPG
supports. Surely there are not many people using ECPG to issue obscure
utility commands like, for example, DROP OPERATOR CLASS.
I haven't tried this to see just how much we'd have to dike out, but
my guess is that we could push the ecpg grammar down to something that
would get through stock bison without omitting anything anyone's even
remotely likely to miss.
This is, of course, an ugly hack that we'd want to undo once more
capable versions of bison are readily available. But I think it could
tide us over for a release or two.
Comments?
regards, tom lane
Tom Lane wrote: > I had a thought about what to do with the ECPG grammar-too-big problem: > rather than depending on a beta release of bison, we could attack the > problem directly by omitting some of the backend grammar from what ECPG > supports. Surely there are not many people using ECPG to issue obscure > utility commands like, for example, DROP OPERATOR CLASS. > > I haven't tried this to see just how much we'd have to dike out, but > my guess is that we could push the ecpg grammar down to something that > would get through stock bison without omitting anything anyone's even > remotely likely to miss. > > This is, of course, an ugly hack that we'd want to undo once more > capable versions of bison are readily available. But I think it could > tide us over for a release or two. > > Comments? I think we should just go with the bison beta for ecpg and be done with it. If we find bugs, we can ask the bison folks to fix it, or work around it ourselves. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Michael Meskes wrote: > Hi, > > I just removed the prepare/execute/deallocate function from ecpg's > parser so there are no conflicts anymore. But for the future (that is > after 7.3 is released) I'd like to work something out. The only problem > I see with using the backend functions is that the backend prepare needs > the data type for each variable and I have no idea how to present it > given the embedded syntax. I take it the backend prepare cannot work > without this info, can it? > > Also I still have some open bug reports but on the other hand few to no > available time. Shall we add these reports to the TODO list? I doubt > I'll be able to fix them ntil release time, at least not all of them. Yes, please send over additional TODO items. Thanks. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> I had a thought about what to do with the ECPG grammar-too-big problem:
>> rather than depending on a beta release of bison, we could attack the
>> problem directly by omitting some of the backend grammar from what ECPG
>> supports.
> I think we should just go with the bison beta for ecpg and be done with
> it. If we find bugs, we can ask the bison folks to fix it, or work
> around it ourselves.
Using the beta bison has a lot of disadvantages though, particularly if
we want to follow the conservative route of using it only for ecpg and
not for the other .y files. How exactly will you cause the build to
work that way? How will you make it work for everyone who pulls CVS
rather than a prebuilt tar file?
Also, I was quite unthrilled when I experimented tonight with bison
1.49b, and found it to be a factor of 16 slower than bison 1.28.
(<2 seconds versus >32 seconds to process the backend gram.y file.)
If they don't fix that, bison 1.49+ will have roughly zero uptake
among real users --- who's going to hold still for that much slowdown,
to get a tool whose only obvious improvement is that it now rejects
optional commas?
Bottom line is that I don't think we can require bison > 1.28 for a
good while yet.
regards, tom lane
On Sun, Sep 22, 2002 at 04:18:23PM -0400, Tom Lane wrote: > I had a thought about what to do with the ECPG grammar-too-big problem: > rather than depending on a beta release of bison, we could attack the > problem directly by omitting some of the backend grammar from what ECPG > supports. Surely there are not many people using ECPG to issue obscure > utility commands like, for example, DROP OPERATOR CLASS. But then there may be one. And I'd prefer to not remove features that used to exist. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> On Sun, Sep 22, 2002 at 04:18:23PM -0400, Tom Lane wrote:
>> I had a thought about what to do with the ECPG grammar-too-big problem:
>> rather than depending on a beta release of bison, we could attack the
>> problem directly by omitting some of the backend grammar from what ECPG
>> supports. Surely there are not many people using ECPG to issue obscure
>> utility commands like, for example, DROP OPERATOR CLASS.
> But then there may be one. And I'd prefer to not remove features that
> used to exist.
What about removing this feature that used to exist: being able to build
ecpg with reasonably-standard tools?
I think you should be setting more weight on that concern than on
supporting obscure backend commands (some of which didn't even exist in
7.2, and therefore are certainly not depended on by any ecpg user...)
regards, tom lane
On Mon, Sep 23, 2002 at 09:56:59AM -0400, Tom Lane wrote: > What about removing this feature that used to exist: being able to build > ecpg with reasonably-standard tools? How many people do use bison themselves? Most people I talked to use the precompiled preproc.c. > I think you should be setting more weight on that concern than on > supporting obscure backend commands (some of which didn't even exist in > 7.2, and therefore are certainly not depended on by any ecpg user...) Which of course would also mean spending quite some time to remove features that have to be added again once bison is released. I will try to get some info from the bison people about the release date. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> On Mon, Sep 23, 2002 at 09:56:59AM -0400, Tom Lane wrote:
>> What about removing this feature that used to exist: being able to build
>> ecpg with reasonably-standard tools?
> How many people do use bison themselves?
*Everyone* who checks out from our CVS needs to build the bison output
files. There seem to be quite a few such people; they will all be
forced to upgrade their local bison installations when ecpg starts
requiring a newer bison.
> I will try to get some info from the bison people about the release
> date.
I just this morning got this response from Akim Demaille concerning a
portability problem in bison 1.49b:
| Thanks for the report, this is addressed in 1.49c. We should upload
| the latter soon.
So I'm guessing that a full release is not just around the corner :-(
regards, tom lane
On Tue, Sep 24, 2002 at 09:53:10AM -0400, Tom Lane wrote: > *Everyone* who checks out from our CVS needs to build the bison output > files. There seem to be quite a few such people; they will all be I though time stamping is done to make sure the .c file is newer than the .y one. > forced to upgrade their local bison installations when ecpg starts > requiring a newer bison. Valid point. > | Thanks for the report, this is addressed in 1.49c. We should upload > | the latter soon. > > So I'm guessing that a full release is not just around the corner :-( Argh. But when we remove features from ecpg I would prefer to just remove pretty obscure stuff and stuff introduced after 7.2 was released so we won't break much. Does anyone have a list of newly added commands? Or do I have to get the diff from CVS? Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!