Re: parse mistake in ecpg connect string

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Wang, Shenhao" <wangsh(dot)fnst(at)cn(dot)fujitsu(dot)com>
Cc: "horikyota(dot)ntt(at)gmail(dot)com" <horikyota(dot)ntt(at)gmail(dot)com>, "Kuroda, Hayato" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: parse mistake in ecpg connect string
Date: 2021-02-08 19:28:47
Message-ID: 720838.1612812527@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Wang, Shenhao" <wangsh(dot)fnst(at)cn(dot)fujitsu(dot)com> writes:
> Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-02-08 19:29:41 Re: small test case for abbrev(cidr)
Previous Message Daniil Zakhlystov 2021-02-08 19:23:53 Re: libpq compression