From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names |
Date: | 2010-06-02 11:16:58 |
Message-ID: | 4C063DAA.2090301@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 02/06/10 09:46, Takahiro Itagaki wrote:
>
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Spangler, Todd | 2010-06-02 13:23:49 | canceling statement due to user request |
Previous Message | Takahiro Itagaki | 2010-06-02 06:46:41 | Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-06-02 11:40:52 | Re: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby |
Previous Message | Russell Smith | 2010-06-02 10:38:35 | Re: Idea for getting rid of VACUUM FREEZE on cold pages |