Alvaro Herrera writes:
> I also admit it didn't occur to me to test the function(s) against
> overlength input when developing it. I wouldn't object to adding code
> to deal with overlength identifies, but I'm not really sure I would
> choose truncation over reporting an error. But whatever it'd
Tom Lane wrote:
> I wrote:
> > Another idea worth considering is to just make the low-level functions
> > do truncation ...
>
> After further thought, there's a bigger-picture issue here, which
> is whether the inputs to the SQL functions in question are intended to
> be raw user input --- in whic
I wrote:
> Another idea worth considering is to just make the low-level functions
> do truncation ...
After further thought, there's a bigger-picture issue here, which
is whether the inputs to the SQL functions in question are intended to
be raw user input --- in which case, not only would truncat
Michael Paquier writes:
> On Sat, Dec 24, 2016 at 7:44 AM, Joe Conway wrote:
>> On 12/23/2016 12:44 PM, Tom Lane wrote:
>>> 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-developer
On Sat, Dec 24, 2016 at 7:44 AM, Joe Conway 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. Se
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 j
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
