Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names
Дата
Msg-id 4C063DAA.2090301@enterprisedb.com
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Ответы Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Список pgsql-hackers
On 02/06/10 09:46, Takahiro Itagaki wrote:
>
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  wrote:
>
>> Hmm, seems that dblink should call truncate_identifier() for the
>> truncation, to be consistent with truncation of table names etc.
>
> Hmmm, we need the same routine with truncate_identifier(), but we hard
> to use the function because it modifies the input buffer directly.
> Since all of the name strings in dblink is const char *, I added
> a bit modified version of the function as truncate_identifier_copy()
> in the attached v2 patch.

Well, looking at the callers, most if not all of them seem to actually 
pass a palloc'd copy, allocated by text_to_cstring().

Should we throw a NOTICE like vanilla truncate_identifier() does?

I feel it would be better to just call truncate_identifier() than roll 
your own. Assuming we want the same semantics in dblink, we'll otherwise 
have to remember to update truncate_identifier_copy() with any changes 
to truncate_identifier().


--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Russell Smith
Дата:
Сообщение: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby