ECPG

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, Pennsylvania 19073

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, Pennsylvania 19073

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!