On Sat, Dec 24, 2016 at 7:44 AM, Joe Conway <m...@joeconway.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
