Re: oh dear ... - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: oh dear ...
Date
Msg-id 3FB59777.1070107@dunslane.net
Whole thread Raw
In response to Re: oh dear ...  ("Marc G. Fournier" <scrappy@postgresql.org>)
Responses Re: oh dear ...  ("Marc G. Fournier" <scrappy@postgresql.org>)
List 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



pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: oh dear ...
Next
From: "Dann Corbit"
Date:
Subject: Re: INSERT extremely slow with large data sets