Re: parse mistake in ecpg connect string

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: parse mistake in ecpg connect string
Дата
Msg-id 720838.1612812527@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: parse mistake in ecpg connect string  ("Wang, Shenhao" <wangsh.fnst@cn.fujitsu.com>)
Ответы RE: parse mistake in ecpg connect string
Список 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 по дате отправления:

Предыдущее
От: Daniil Zakhlystov
Дата:
Сообщение: Re: libpq compression
Следующее
От: Tom Lane
Дата:
Сообщение: Re: small test case for abbrev(cidr)