varchar truncation from 7.1 to 7.2

From: Jeff Davis <list-pgsql-general(at)empires(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: varchar truncation from 7.1 to 7.2
Date: 2002-08-02 02:01:02
Message-ID: 200208011436.04605.list-pgsql-general@empires.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2002-08-02 02:22:50 Re: varchar truncation from 7.1 to 7.2
Previous Message Ben Liblit 2002-08-02 01:52:41 huge performance penalty from constraint triggers