Re: Unexpected casts while using date_trunc() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Unexpected casts while using date_trunc()
Date
Msg-id 5099.1527259315@sss.pgh.pa.us
Whole thread Raw
In response to Re: Unexpected casts while using date_trunc()  (Chris Bandy <bandy.chris@gmail.com>)
List pgsql-hackers
Chris Bandy <bandy.chris@gmail.com> writes:
> On 5/24/18 2:31 PM, Tom Lane wrote:
>> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>>> 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.

> Are we in agreement that the return type should be date?

That is a good question, actually.  That would be a larger behavior change
than just avoiding the undesired conversion to TZ.  I had imagined this
as just being equivalent to date_trunc(text, date::timestamp).  Casting
the result back down to date seems safe, though.

Another thing to consider is that the effective range of date is wider
than timestamp's, meaning coerce-to-timestamp can fail.  Is it worth
providing a whole additional code path so we never coerce the date to
timestamp at all?  I'd tend to think not, but perhaps somebody wants to
argue differently.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Avoiding Tablespace path collision for primary and standby
Next
From: Robert Haas
Date:
Subject: Re: SCRAM with channel binding downgrade attack