Re: parse mistake in ecpg connect string - Mailing list pgsql-hackers

From Tom Lane
Subject Re: parse mistake in ecpg connect string
Date
Msg-id 720838.1612812527@sss.pgh.pa.us
Whole thread Raw
In response to RE: parse mistake in ecpg connect string  ("Wang, Shenhao" <wangsh.fnst@cn.fujitsu.com>)
Responses RE: parse mistake in ecpg connect string
List pgsql-hackers
"Wang, Shenhao" <wangsh.fnst@cn.fujitsu.com> writes:
> Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
>> FWIW, directly embedding /unixsocket/path syntax in a URL is broken in
>> the view of URI. It is the reason why the current connection URI takes
>> the way shown above. So I think we want to remove that code rather
>> than to fix it.

> It seems that remove that code is better.

FWIW, I agree with Horiguchi-san that we should just take out the dead
code in ECPGconnect().  Some checking in our git history shows that it's
never worked since it was added (in a4f25b6a9c2).  If nobody's noticed
in 18 years, and the documentation doesn't say that it should work,
then that's not a feature we need to support.

I do agree that it'd be a good idea to extend the documentation to
point out how to specify a non-default socket path; but I'm content
to say that a "?host=" option is the only way to do that.

I also got a bit of a laugh out of

                    if (strcmp(dbname + offset, "localhost") != 0 && strcmp(dbname + offset, "127.0.0.1") != 0)

Should we allow "::1" here as well?  On the other hand, colons are
already overloaded in this syntax, so maybe allowing them in the
host part is a bad idea.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Daniil Zakhlystov
Date:
Subject: Re: libpq compression
Next
From: Tom Lane
Date:
Subject: Re: small test case for abbrev(cidr)