| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Meskes <meskes(at)postgresql(dot)org> |
| Cc: | PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ECPG |
| Date: | 2002-09-23 13:56:59 |
| Message-ID: | 21054.1032789419@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Meskes <meskes(at)postgresql(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-09-23 14:01:06 | Re: DROP COLUMN misbehaviour with multiple inheritance |
| Previous Message | Shridhar Daithankar | 2002-09-23 13:56:57 | Re: Postgresql Automatic vacuum |