Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names
Date
Msg-id 4C063DAA.2090301@enterprisedb.com
Whole thread Raw
In response to Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
List 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 by date:

Previous
From: Russell Smith
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Next
From: Heikki Linnakangas
Date:
Subject: Re: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby