Re: Long strings, short varchars - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Long strings, short varchars
Date
Msg-id 29695.1029434526@sss.pgh.pa.us
Whole thread Raw
In response to Re: Long strings, short varchars  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Long strings, short varchars
Next
From: "Scott"
Date:
Subject: bug in config for cygwin