Re: oh dear ...

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: oh dear ...
Date: 2003-11-15 03:03:19
Message-ID: 3FB59777.1070107@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marc G. Fournier wrote:

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

I'm confused. My understanding from what Tom said is that it affects all
configurations.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2003-11-15 03:21:18 Re: ALTER TABLE modifications
Previous Message Marc G. Fournier 2003-11-15 02:39:02 Re: oh dear ...