Re: dblink versus long connection strings

Поиск
Список
Период
Сортировка
От Itagaki Takahiro
Тема Re: dblink versus long connection strings
Дата
Msg-id AANLkTikDmUkqaK0sZ59NPQ80W_uA9SY4sZJdDSv9BLuj@mail.gmail.com
обсуждение исходный текст
Ответ на dblink versus long connection strings  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: dblink versus long connection strings  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Nov 23, 2010 at 01:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This bug report:
> http://archives.postgresql.org/pgsql-bugs/2010-11/msg00139.php
> shows that this patch was ill-considered:
> http://archives.postgresql.org/pgsql-committers/2010-06/msg00013.php
> and this later attempt didn't fix it, because it still misbehaves in
> HEAD:
> http://archives.postgresql.org/pgsql-committers/2010-06/msg00070.php
> not to mention that that second patch didn't even touch pre-8.4
> branches.
>
> I'm inclined to think that we should just change all the
> truncate_identifier calls to warn=false, and forget about providing
> identifier-truncated warnings here.  It's too difficult to tell whether
> a string is really meant as an identifier.

It is not a truncated identifier, but I think the truncation is still
worth warning because we cannot distinguish two connections that
differ only >63 bytes.

Do we need another logic to name non-named connections?
For example, md5 hash of the connection string.

--
Itagaki Takahiro


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: directory archive format for pg_dump