Re: ECPG could not connect to the database.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: ECPG could not connect to the database.
Date: 2001-01-09 17:11:58
Message-ID: 1354.979060318@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Michael Meskes <meskes(at)postgresql(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Lee Joramo 2001-01-09 17:20:39 Re: COPY error: pqReadData() -- backend closed the channel unexpectedly
Previous Message Tom Lane 2001-01-09 17:05:16 Re: Re: Advice on stored proc error handling versus Sybase?