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
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? |