Re: Current enums patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tom Dunstan <pgsql(at)tomd(dot)cc>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Current enums patch
Date: 2007-04-02 18:45:06
Message-ID: 26329.1175539506@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Dunstan <pgsql(at)tomd(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2007-04-02 19:16:59 Re: Current enums patch
Previous Message Tom Dunstan 2007-04-02 18:39:52 Re: Current enums patch