>> Hm, I suppose we should apply truncate_identifier rather than letting
>> the strings be blindly truncated (perhaps in mid-character). Should we
>> have it throw the truncation NOTICE, or not? First thought is to do so
>> during CREATE TYPE but not during plain enum_in().
>>
>
> I don't see much point in truncating.
>
> The patch I have so far gives the regression output shown below (yes, I
> should make the messages more consistent).
>
> In fact the truncation and associated NOTICE just strike me as confusing.
[snip]
> + ERROR: input value too long (74) for enum:
> "abcdefghijklmnopqrsatuvwxyz012345 etc etc
I was about to suggest that we just truncate the value in the input
function and look it up on the basis that if it's too long, the lookup
will fail and we can just tell the user that it wasn't a valid value.
But if there's a valid value that has the same 63 bytes as the first 63
of the too-long input string, we'll end up looking up the valid one
wrongly. So we do need to test for length and die at that point. Can we
just fail with the same error message as trying to input a smaller, but
similarly invalid string?
At create time, we should definitely throw an error... if we just
truncate the value at byte 64 (with a notice or not) we might truncate
in the middle of a multi-byte character. Yuk.
Cheers
Tom
