Re: Current enums patch - Mailing list pgsql-patches

From Tom Lane
Subject Re: Current enums patch
Date
Msg-id 26329.1175539506@sss.pgh.pa.us
Whole thread Raw
In response to Re: Current enums patch  (Tom Dunstan <pgsql@tomd.cc>)
Responses Re: Current enums patch
Re: Current enums patch
List pgsql-patches
Tom Dunstan <pgsql@tomd.cc> writes:
> 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.

While all this reasoning is perfectly OK on its own terms, it ignores
the precedents of SQL identifier handling.  Maybe we should revisit the
question of whether the labels are identifiers.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Dunstan
Date:
Subject: Re: Current enums patch
Next
From: Gregory Stark
Date:
Subject: Re: Blocked post