Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
От | Peter Eisentraut |
---|---|
Тема | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
Дата | |
Msg-id | 097a4242-0748-98e3-06ab-ded1d366cd76@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
|
Список | pgsql-hackers |
On 2020-09-07 01:46, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> Here is a new patch series version. >> I have created a new internal function for converting integers to >> numeric, to make the implementation a bit more elegant and compact. > > I reviewed the 0002 patch, finding one bug (in int8_sum) Ouch, no test coverage. Should we perhaps remove this function, since it's obsolete and unused? > and a few > more calls of int8_numeric that could be converted. I think the > attached updated version is committable, and I'd recommend going > ahead with that regardless of the rest of this. I hadn't realized > how many random calls of int8_numeric and int4_numeric we'd grown, > but there are a lot, so this is nice cleanup. Yes, please go ahead with it. > I continue to think that we can't commit 0003 in this form, because > of the breakage that will ensure in stored views. As I said upthread, > we should leave the existing SQL-exposed functions alone, invent > new ones that return numeric, and alter the parser to translate > EXTRACT constructs to the new functions. This approach would also > provide an "out" for anyone who does complain about the performance > cost --- they can just continue to use the old functions. Okay, I will continue looking into this. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: