Re: ECPG could not connect to the database. - Mailing list pgsql-general

From Tom Lane
Subject Re: ECPG could not connect to the database.
Date
Msg-id 1354.979060318@sss.pgh.pa.us
Whole thread Raw
In response to Re: ECPG could not connect to the database.  (Michael Meskes <meskes@postgresql.org>)
Responses Re: ECPG could not connect to the database.
List pgsql-general
Michael Meskes <meskes@postgresql.org> writes:
> On Mon, Jan 08, 2001 at 06:20:42PM +0100, Peter Eisentraut wrote:
>>>> is not in libpq's current sources anymore.  I fully agree with Peter E's
>>>> reasons for removing it, too.  We do not need to overload the definition
>>>> of libpq's dbname parameter.

> Why? Sorry, it seems I missed his mail.

Check pghackers from late November or so.  But in brief --- the code is
broken, it's not documented (at least not in the libpq documentation),
it interferes with accessing databases whose names contain funny
characters, and it looks likely to create compatibility problems with
future standards.  It also didn't play well with the Unix-socket-path-
specification change, IIRC.

>> Ouch, it *is* documented in ecpg(1).  I guess if ecpg wants to provide
>> this syntax (which it probably should, since the "sql connect to" syntax
>> doesn't have any other provisions for host name, port, etc.) then it could
>> take the code from libpq (it's still in there I think) and do the parsing
>> before calling PQsetdbLogin().

> This is a possibility of course. But why should this syntax be taken away
> from other apps using libpq?

It's not being "taken away" from other apps, because there are no other
apps using it, because it's not documented as a feature of anything
except ecpg.

            regards, tom lane

pgsql-general by date:

Previous
From: mkennedy@hssinc.com (Matthew Kennedy)
Date:
Subject: is there a vendor independent C API for DB development?
Next
From: Lee Joramo
Date:
Subject: Re: COPY error: pqReadData() -- backend closed the channel unexpectedly