Re: Bizarre 7.3.2 bug

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Larry Rosenman <ler(at)lerctr(dot)org>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bizarre 7.3.2 bug
Date: 2003-04-22 06:01:10
Message-ID: 20030422060110.GD79923@perrin.int.nxad.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 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

--
Sean Chittenden

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-04-22 06:09:51 Re: Bizarre 7.3.2 bug
Previous Message Neil Conway 2003-04-22 06:00:24 FYI: away for the summer