Re: dblink versus long connection strings
От | Andrew Dunstan |
---|---|
Тема | Re: dblink versus long connection strings |
Дата | |
Msg-id | 4CEAA23E.3020609@dunslane.net обсуждение исходный текст |
Ответ на | Re: dblink versus long connection strings (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: dblink versus long connection strings
|
Список | pgsql-hackers |
On 11/22/2010 11:51 AM, Tom Lane wrote: > Itagaki Takahiro<itagaki.takahiro@gmail.com> writes: >> On Tue, Nov 23, 2010 at 01:27, Tom Lane<tgl@sss.pgh.pa.us> wrote: >>> 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. > The problem is to not give a warning when the string isn't meant as a > connection name at all, but as a libpq conninfo string (which can > perfectly reasonably run to more than 63 characters). Most if not all > of the dblink functions will accept either. > > Perhaps a reasonable compromise is to issue the truncation warnings when > an overlength name is being *entered* into the connection table, but not > for simple lookups. Can't we distinguish a name from a conninfo string by the presence of an = sign? cheers andrew
В списке pgsql-hackers по дате отправления: