From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: oh dear ... |
Date: | 2003-11-15 02:39:02 |
Message-ID: | 20031114223849.Y497@ganymede.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 14 Nov 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > I said:
> > > This worked in 7.3:
> > > regression=# select '1999-jan-08'::date;
> > > ERROR: date/time field value out of range: "1999-jan-08"
> > > HINT: Perhaps you need a different "datestyle" setting.
> >
> > > Setting DateStyle to YMD doesn't help, and in any case I'd think that
> > > this ought to be considered an unambiguous input format.
> >
> > This appears to be an oversight in the portions of the datetime code
> > that we recently changed to enforce DateStyle more tightly.
> > Specifically, DecodeNumber was rewritten without realizing that it was
> > invoked in a special way when a textual month name appears in the input.
> > DecodeDate actually makes two passes over the input, noting the textual
> > month name in the first pass, and then calling DecodeNumber on only the
> > numeric fields in the second pass. This means that when DecodeNumber is
> > called for the first time, the MONTH flag may already be set. The
> > rewrite mistakenly assumed that in this case we must be at the second
> > field of an MM-DD-YY-order input.
> >
> > I propose the attached patch to fix the problem. It doesn't break any
> > regression tests, and it appears to fix the cases noted in its comment.
> >
> > Opinions on whether to apply this to 7.4?
>
> I guess the question is whether we would fix this in a minor release,
> and I think the answer it yes, so we can fix it now.
Ah, so we attempt to fix a bug that affects what appears to be a small %
of configurations with "quick testing" and with the greater possibility of
affecting a larger % of configurations ... instead of releasing what we
has been reported as being stable on the large % of configurations, and
fixing it for that small % of configuratiosn in a minor release?
Sounds to me like a decision design to benefit the few at the risk of the
many ... when documenting the known bug for those few would be safer ...
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2003-11-15 03:03:19 | Re: oh dear ... |
Previous Message | Bruce Momjian | 2003-11-15 02:17:08 | Re: oh dear ... |