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

From Takahiro Itagaki
Subject Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names
Date
Msg-id 20100602154641.950B.52131E4D@oss.ntt.co.jp
Whole thread Raw
In response to Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
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.

> I also spotted this in dblink.c:
>
> >     /* first gather the server connstr options */
> >     if (strlen(servername) < NAMEDATALEN)
> >         foreign_server = GetForeignServerByName(servername, true);
>
> I think that's wrong. We normally consistently truncate identifiers at
> creation and at use, so that if you create an object with a very long
> name and it's truncated, you can still refer to it with the untruncated
> name because all such references are truncated too.

Absolutely. I re-use the added function for the fix.

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center


Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby
Next
From: Greg Smith
Date:
Subject: Re: Synchronization levels in SR