Re: NOT EXIST for PREPARE

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

In response to

Responses

Browse pgsql-hackers by date

  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