From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Incautious handling of overlength identifiers |
Date: | 2016-12-23 22:44:18 |
Message-ID: | ed23895f-c3b5-e42c-7a79-c676378c34da@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/23/2016 12:44 PM, Tom Lane wrote:
> I wrote:
>> So what to do? We could run around and fix these individual cases
>> and call it good, but if we do, I will bet a very fine dinner that
>> more such errors will sneak in before long. Seems like we need a
>> coding convention that discourages just randomly treating a C string
>> as a valid value of type NAME. Not sure how to get there though.
>
> An alternative worth considering, especially for the back branches,
> is simply to remove the Assert in hashname(). That would give us
> the behavior that non-developers see anyway, which is that these
> functions always fail to match overlength names, whether or not
> the names would have matched after truncation. Trying to apply
> truncation more consistently could be left as an improvement
> project for later.
That sounds reasonable to me.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-12-23 22:48:42 | Re: Time to retire Windows XP buildfarm host? |
Previous Message | Michael Paquier | 2016-12-23 22:33:24 | Re: Clarifying "server starting" messaging in pg_ctl start without --wait |