Re: Bizarre 7.3.2 bug - Mailing list pgsql-hackers

> >> The obvious solution to this sort of problem would be to
> >> introduce a GUC variable ("allow_zero_length_integers" or some
> >> such name).  I do not recall why we decided not to do that to
> >> begin with --- should we reconsider, or is it too late to worry
> >> about it?
> 
> > I agree that, in the future, using a GUC variable is the best way
> > to manage these kinds of backward-incompatible changes. When this
> > was suggested for the pg_atoi problem some time after the 7.3
> > release, someone (you, I believe) suggested that it was too late
> > to add a GUC variable at that point.
> 
> I think I did opine that way --- but I too am open to being
> persuaded.  Adding a simple boolean GUC variable is foolproof enough
> that I don't believe it could break anything, and so the rationale
> for the "no new features in stable releases" rule doesn't really
> apply.  The argument that has to be answered at this point is
> "hasn't everyone who's not completely asleep at the wheel already
> fixed their application code?  How much should we cater to them as
> are asleep?"

Well, as I mentioned to Neil on IRC, too much time has been spent on
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
conditionthat 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
andtool authors will  cater to the list of GUCs available.  Putting this behind a #define  would be better.  Supporting
everyquirk 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

-- 
Sean Chittenden