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
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 |