Re: Incautious handling of overlength identifiers

On Sat, Dec 24, 2016 at 7:44 AM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> 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.

+1 for just removing the assertion on back-branches. On HEAD, it seems
right to me to keep the assertion. However it is not possible to just
switch those routines from text to name as a table could be defined
with its schema name. So at minimum this would require adjusting
textToQualifiedNameList() & similar routines in charge of putting in
shape the name lists. Another idea would be to have as a data type an
idea of "qualified name", where the schema and the table names are
truncated automatically at 63 characters, and have those catalog use
it. This way the parsing and truncation logic are directly part of the
input and output functions, and we could assume that the internal
representation is a list of names.
--
Michael