Re: oh dear ...
От | Andrew Dunstan |
---|---|
Тема | Re: oh dear ... |
Дата | |
Msg-id | 3FB59777.1070107@dunslane.net обсуждение исходный текст |
Ответ на | Re: oh dear ... ("Marc G. Fournier" <scrappy@postgresql.org>) |
Ответы |
Re: oh dear ...
|
Список | 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 по дате отправления: