Re: Redhat 7.3 time manipulation bug
От | Trond Eivind Glomsrød |
---|---|
Тема | Re: Redhat 7.3 time manipulation bug |
Дата | |
Msg-id | Pine.LNX.4.44.0205211500500.23153-100000@halden.devel.redhat.com обсуждение исходный текст |
Ответ на | Re: Redhat 7.3 time manipulation bug (Manuel Sugawara <masm@fciencias.unam.mx>) |
Ответы |
Re: Redhat 7.3 time manipulation bug
|
Список | pgsql-hackers |
On 21 May 2002, Manuel Sugawara wrote: > Trond Eivind Glomsrød <teg@redhat.com> writes: > > > Relying on nonstandardized/nondocumented behaviour is a program bug, > > not a glibc bug. > > The question is: how this thing didn't show up before? ISTM that > someone is not doing his work correctly. FWIW, I ran the regressions tests some time ago(probably before that change to glibc) . Since the tests are known to be broken wrt. time issues anyway (as well as currency, math and sorting), it's easy to overlook. > > PostgreSQL needs fixing. > > Arguably, however, right now is *a lot easier* to fix glibc, and it's > really needed for production systems using postgreSQL and working on > RedHat. You're not "fixing" glibc, you're reintroducing non-standardized, upstream removed behaviour. That's typically a very bad thing. If anything, it demonstrates the importance of not using or relying on unstandardized/undocumented behaviour (and given that time_t is pretty restrictive anyway, you'll need something else to keep dates. It doesn't even cover all living people, and definitely not historical dates). > > Since we ship both, we're looking at it, but glibc is not the > ^^^^^^^^^^^^^^^^^^^ > The sad true is: you only answered when the 'Complain to Red Hat' > statement appeared, not a single word before and not a single word > when the bug report were closed. I'm really disappointed. The bug wasn't open for long, and was closed by someone else. > The nice thing is: glibc is free software Also, notice that this was where the fix came from: The upstream maintainers (some of whom work for us, others don't). -- Trond Eivind Glomsrød Red Hat, Inc.
В списке pgsql-hackers по дате отправления: