Re: [HACKERS] threads stuff/UnixWare
От | Larry Rosenman |
---|---|
Тема | Re: [HACKERS] threads stuff/UnixWare |
Дата | |
Msg-id | 535C3F223F28824E69EE268D@lerlaptop.lerctr.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] threads stuff/UnixWare (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
--On Friday, May 14, 2004 09:41:58 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Larry Rosenman <ler@lerctr.org> writes: >> Reply from SCO: > >> Indeed. For "inf", "infinity", and "nan", but not >> "nan(digits)", the pointer is left at the trailing >> matched character instead of the next. > >> Moreover, checking our source history, it has been >> broken this way for nearly 12 years. Couldn't you >> folks have noticed this bug a little sooner!? :-) > > Doesn't give one a warm feeling for the average level of error checking > in Unix programs, does it? nope.... > >> I gather from this that it will be fixed in the first maint packs >> for 7.1.4. > > Good. I'd say we just leave it for that then. > Ok, but see below. >> Is there some way we can work around this? > > I don't want to, because it would compromise the error checking. > For instance, if we hack the code to accept this behavior, then > it would also accept "NaNN" as soon as SCO fixes their bug. Won't this change behaviour for select 'NaN'::float8 etc such that Applications might fail? > > The regression tests exist to discover platform bugs as well as > Postgres bugs. In this case, I think having them fail on unpatched > SCO platforms is exactly what should happen. > > If you want, you can send in a docs patch for FAQ_SCO to give > people a clue about it. OK. See above comment, etc. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Вложения
В списке pgsql-patches по дате отправления: