Re: Unexpected casts while using date_trunc()
От | Chris Bandy |
---|---|
Тема | Re: Unexpected casts while using date_trunc() |
Дата | |
Msg-id | 47a9834c-330d-5e31-0188-58bfe1ac9245@gmail.com обсуждение исходный текст |
Ответ на | Re: Unexpected casts while using date_trunc() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Unexpected casts while using date_trunc()
|
Список | pgsql-hackers |
On 5/24/18 2:31 PM, Tom Lane wrote: > Andrew Gierth <andrew@tao11.riddles.org.uk> writes: >> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: >> Tom> Yeah. There are two relevant variants of date_trunc(): >> [...] >> Tom> So we probably ought to change the docs here. > >> There's also the option of adding an explicit function >> date_trunc(text,date) returns date, which is a workaround that I (and >> probably quite a few other people) have used. I think having such a >> function added to core would be less surprising than the current >> behavior. > > Ah! Yes, of course, that would be better. Seems like a workable > solution for Chris, too. We still can't back-patch it, though. > > regards, tom lane > I could take a pass at this about two weeks from now. (I won't be sad if someone else beats me to it.) Are we in agreement that the return type should be date? I wasn't able to find a definitive reference for the expected behavior of date_trunc. Shall I replicate the behavior of casting to/from timestamp? What should happen when the user requests some time portion (e.g. hour) be truncated? -- Chris
В списке pgsql-hackers по дате отправления: