Re: float8 regression failure (HEAD, cygwin)
От | Andrew Dunstan |
---|---|
Тема | Re: float8 regression failure (HEAD, cygwin) |
Дата | |
Msg-id | 44CF4FC4.7070802@dunslane.net обсуждение исходный текст |
Ответ на | Re: float8 regression failure (HEAD, cygwin) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: float8 regression failure (HEAD, cygwin)
|
Список | pgsql-hackers |
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> Maybe we need to abandon trying to map float8 results exactly in the >> resultmap file, and just let pg_regress pick the best fit as we do with >> some other tests. >> > > I thought about that too but it seems a very bad idea. small-is-zero is > distinctly "less correct" than the regular output, and I don't think we > want pg_regress to be blindly accepting it as OK on any platform. > > Perhaps we could stick a version check into the resultmap lookup? It'd > likely have been painful on the shell script implementation but now that > the code is in C I think we have lots of flexibility. There's no need > to feel bound by the historical resultmap format. > > However this is all premature unless we can verify that "cgywin's strtod() > complains about float underflow after version so-and-so". Do they > publish a detailed change log? > > > Yes, good points. One other thought I had was that we could have pg_regress always allow a fallback to the canonical result file. So in this case it would try float8-small-is-zero.out and float8-small-is-zero_1.out and finally float8.out (the first would succeed on eel, the last on cassowary, I am speculating). In general this would allow a configuration to become more correct painlessly. cheers andrew
В списке pgsql-hackers по дате отправления: