Re: [BUGS] Long strings, short varchars

In PostgreSQL 7.1, this code goes smoothly.

create table test (name varchar(5));
insert into test values('abracadabra');

Long input string was silently trimmed. But in PG7.2 an error is triggered.

OK, I suppose this is just a new feature, not a bug but. But...

...Is it possible to restore the old behaviour?

--
Best regards,
Sasa Markovic, Development Team Leader
DataGate Belgrade - http://www.datagate.co.yu

Sasa Markovic writes:

> Long input string was silently trimmed. But in PG7.2 an error is triggered.
> OK, I suppose this is just a new feature, not a bug but. But...
> ...Is it possible to restore the old behaviour?

Write a rule that truncates the string before it's inserted.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Sasa Markovic writes:
>> Long input string was silently trimmed. But in PG7.2 an error is triggered.
>> OK, I suppose this is just a new feature, not a bug but. But...
>> ...Is it possible to restore the old behaviour?

> Write a rule that truncates the string before it's inserted.

Peter, did you note the thread that concluded we'd not got the SQL
semantics quite right here? AFAICT, raising an error when an overlength
string is assigned is correct per spec, but raising an error when an
overlength string is explicitly casted is *not* correct. Something like

select 'foo'::char(2);

should draw a "completion condition" not an "exception condition" per
spec. Compare SQL92 6.10 <cast specification> general rules 5.c and 6.c
with 9.2 store assignment general rules 3.b and 3.e; the one set says
completion condition, the other says exception condition.

A completion condition might be thought to be the same as our WARNING,
but I'd be inclined to argue on usability grounds that the cast case
should just silently truncate.

In any case we need to distinguish implicit coercion for a store from
explicit coercion. Do your recent pg_cast changes make that any easier?

regards, tom lane

Tom Lane writes:

> In any case we need to distinguish implicit coercion for a store from
> explicit coercion. Do your recent pg_cast changes make that any easier?

Possibly we could allow for registering both implicit and explicit cast
functions for the same combination. Or we could make cast functions take
an optional second argument that tells whether the cast is implicit or
explicit. We probably also need to take into account the typemod coercion
functions that are currently handled in a semi-internal way. (Any
formalization of those should probably consider the possibility of
allowing typemods on arbitrary types.) Not sure which way to go.

--
Peter Eisentraut peter_e(at)gmx(dot)net