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, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5487: dblink failed with 63 bytes connection names |
Date: | 2010-06-01 09:00:23 |
Message-ID: | 4C04CC27.8090006@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 01/06/10 05:55, Takahiro Itagaki wrote:
> "Takahiro Itagaki"<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
>>
>> Contib/dblink module seems to have a bug in handling
>> connection names in NAMEDATALEN-1 bytes.
>
> Here is a patch to fix the bug. I think it comes from wrong usage
> of snprintf(NAMEDATALEN - 1). It just copies 62 bytes + \0.
>
> In addition, it should be safe to use pg_mbcliplen() to truncate
> extra bytes in connection names because we might return invalid
> text when a multibyte character is at 62 or 63 bytes.
Hmm, seems that dblink should call truncate_identifier() for the
truncation, to be consistent with truncation of table names etc.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | viras | 2010-06-01 13:24:06 | Re: BUG #5484: sum() bug |
Previous Message | Pavel Stehule | 2010-06-01 04:44:49 | Re: Bug in CREATE FUNCTION with character type (CONFIRMED BUG) |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-06-01 09:08:37 | Re: [RFC] A tackle to the leaky VIEWs for RLS |
Previous Message | KaiGai Kohei | 2010-06-01 08:39:41 | [RFC] A tackle to the leaky VIEWs for RLS |