| From: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names |
| Date: | 2010-06-02 06:46:41 |
| Message-ID: | 20100602154641.950B.52131E4D@oss.ntt.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
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.
> 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 | Content-Type | Size |
|---|---|---|
| dblink_63bytes-2010602.patch | application/octet-stream | 3.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2010-06-02 11:16:58 | Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names |
| Previous Message | viras | 2010-06-02 05:13:37 | Re: BUG #5484: sum() bug |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2010-06-02 07:22:42 | Re: Synchronization levels in SR |
| Previous Message | Fujii Masao | 2010-06-02 03:23:33 | Re: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby |