varchar truncation from 7.1 to 7.2 - Mailing list pgsql-general

From Jeff Davis
Subject varchar truncation from 7.1 to 7.2
Date
Msg-id 200208011436.04605.list-pgsql-general@empires.org
Whole thread Raw
Responses Re: varchar truncation from 7.1 to 7.2  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-general
I know that 7.2 started raising an error when a string is too long for a
varchar, whereas 7.1 silently truncated it.

My question is: why?

I read some previous posts about it, and the solution seemed to be a per-table
trigger to truncate the new value first (Thanks Jan).

Now, I don't think it's a problem if the behavior was always that way. If
every other database threw an error, that would also make sense (I am pretty
sure that db2 silently truncates).

However, it does seem to be a problem (albeit very minor) because it's (a) a
change from previous releases and (b) not always helpful.

If you send a query, and there is an obvious, sane, safe, predictable
way to make it work, I think that's the correct course of action. Moreover,
there really isn't a way for you to know that you've made an application
programming error until it's in production anyway (with the current behavior
or prior behavior), so I don't see how it helps you debug anything.

Am I missing a strong gain here? Again, this is a really minor issue. Overall
I'm really happy with 7.2.1 (which I just put on my production systems, in
case you're curious what prompted this question).

Thanks,
    Jeff



pgsql-general by date:

Previous
From: Ben Liblit
Date:
Subject: huge performance penalty from constraint triggers
Next
From: Bruce Momjian
Date:
Subject: Re: varchar truncation from 7.1 to 7.2