From: | Michael Meskes <meskes(at)postgresql(dot)org> |
---|---|
To: | Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru> |
Cc: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: NOT EXIST for PREPARE |
Date: | 2016-03-24 07:32:44 |
Message-ID: | 1458804764.1914.39.camel@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I want to understand the situation. You may want to make the build
> ecpg
> optional. Personally, I want to.
You lost me here, sorry. What exactly do you want to do?
While ecpg may not be the choice for new applications, there are a lot
of legacy applications out there that need ecpg to be migrated to
PostgreSQL. So I think, completely removing it is out of the question.
An optional build does not change a thing because it still has to
compile et al. If you mean you'd like to decouple it from the backend
build, that one is difficult because the parser is supposed to accept
exactly the same SQL. And we spend quite a bit of effort to make it
auto-build from the backend parser to make sure we don't lose any
changes.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2016-03-24 08:18:51 | Re: Relation extension scalability |
Previous Message | Michael Paquier | 2016-03-24 07:24:13 | Re: snapshot too old, configured by time |