Sam Mason <s...@samason.me.uk> writes:
> Would something like the included patch be accepted?
> [ patch to make charin() throw error for excess input ]
I remembered the reason why this idea got rejected previously.
The winning argument was that "char" should behave as nearly
as possible like the standard type char(1). And guess what,
that truncates silently:
regression=# select 'foo'::char(1);
bpchar
--------
f
(1 row)
However, I think we forgot that that is only true for an explicit
coercion to char. If you do this:
regression=# create table fool (f1 char(1));
CREATE TABLE
regression=# insert into fool values('123');
ERROR: value too long for type character(1)
(I'm too lazy to go look up chapter and verse, but all of this is per
SQL standard. Consistency ain't their strong point.)
I certainly don't want to have "char" emulate the misbegotten decision
to have explicit and implicit coercions behave differently. So it
looks to me like the argument to make "char" work like char(1) doesn't
actually help us much to decide if an error should be thrown here or
not. On the whole, throwing an error seems better from a usability
perspective.
Comments?
regards, tom lane
PS: I would suggest that we borrow the wording and SQLSTATE of the
existing message, if we do make it throw an error.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
