Re: [HACKERS] Incautious handling of overlength identifiers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Incautious handling of overlength identifiers
Date
Msg-id 20641.1482525852@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] Incautious handling of overlength identifiers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Incautious handling of overlength identifiers  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Parallel Index-only scan
Next
From: David Steele
Date:
Subject: Re: [HACKERS] Remove lower limit on checkpoint_timeout?