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()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Reiss
Дата:
Сообщение: Performance regression with PostgreSQL 11 and partitioning
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Enhancement Idea - Expose the active value of a parameter in pg_settings