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









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 LeaderDataGate Belgrade - http://www.datagate.co.yu
Wed, 14 Aug 2002 20:41:29 +0200
"Sasa Markovic" <saxon@eunet.yu>
Long strings, short varchars
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


Thu, 15 Aug 2002 19:13:42 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Long strings, short varchars
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

Thu, 15 Aug 2002 14:02:06 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Long strings, short varchars 
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@gmx.net


Tue, 20 Aug 2002 20:03:28 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: [BUGS] Long strings, short varchars 