Thread: 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@gmx.net

Peter Eisentraut <peter_e@gmx.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