Re: Unexpected casts while using date_trunc()

On 5/24/18 2:31 PM, Tom Lane wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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