Re: Bizarre 7.3.2 bug

On Mon, 21 Apr 2003, Sean Chittenden wrote:

> this as is, IMHO so minimal effort/time should be spent on it. Here
> are my thoughts on this:
>
> 1) Roll the ERROR back to a WARNING: doesn't really break anything
> other than POLS re: an out of the way error condition that broken
> code depends on. Please correct my assertion if I'm wrong.
>
> 2) Keep things as an error in 7.4.
>
> 3) Add an upgrading note in the 7.4 release notes to the extent of
> ''::INT is now an error and code must be fixed accordingly. Major
> version bumps are the only time that most developers fix their code
> and look at release notes anyway.
>
> 4) Don't use a GUC for this feature. Using a GUC sets a precedent for
> supporting a feature that's been depreciated and tool authors will
> cater to the list of GUCs available. Putting this behind a #define
> would be better. Supporting every quirk of external applications
> when PostgreSQL changes its behavior is an anti-feature that should
> be avoided.
>
> What's the harm/problem with changing things back to a warning? -sc

I can see the situation where, rightly or wrongly, someone is actually relying
on the transaction being aborted and detecting an error in the broken statement
will be caught out by changing to a warning.

I say leave as an error. Let *BSD patch if they want, but let's not encourage
empty string to take meanings it doesn't have. This is just as bad as assuming
empty string means null. Indeed, given the call for empty string to mean null
from 'compatibility' folk when exactly should the backend assume 0 and not
null?

--
Nigel J. Andrews