Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] possible ecpg vpath build error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: Michael Glaesemann <grzm(at)seespotcode(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] possible ecpg vpath build error
Date: 2006-09-04 15:09:33
Message-ID: 24153.1157382573@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Michael Meskes <meskes(at)postgresql(dot)org> writes:
> On Mon, Sep 04, 2006 at 12:06:02AM -0400, Tom Lane wrote:
>> The backend utils/adt/ code gets to rely on the backend's
>> error handling and memory management protocols, which I surely do
>> not propose to remove, but how could we keep common sources when
>> ecpglib has to work in a far less friendly environment?

> We could modify the backend code to use pgtypeslib, but that would cost
> at least a little bit of performance I would guess.

I'd prefer to go in the other direction: provide enough infrastructure
in ecpglib that it can use the unmodified backend sources.  It would
probably not take too much code to provide minimal elog and palloc
support ... the question is what else would we need?

(BTW, if anyone is working on making that pie-in-the-sky TODO list,
here's a pet peeve for it: ecpg's bison parser should be auto-generated
from the backend's, instead of derived manually.)

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-09-04 15:13:25
Subject: Re: [COMMITTERS] pgsql: sslinfo contrib module - information about current SSL
Previous:From: Peter EisentrautDate: 2006-09-04 15:07:46
Subject: pgsql: sslinfo contrib module - information about current SSL

pgsql-patches by date

Next:From: Tom LaneDate: 2006-09-04 15:49:52
Subject: Re: [PATCHES] Contrib module to examine client
Previous:From: Michael GlaesemannDate: 2006-09-04 14:54:42
Subject: Fix PGPORT reassignment in ecpg regression tests

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group