Re: Unexpected casts while using date_trunc()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Unexpected casts while using date_trunc()
Дата
Msg-id 5099.1527259315@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Unexpected casts while using date_trunc()  (Chris Bandy <bandy.chris@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Avoiding Tablespace path collision for primary and standby
Следующее
От: Robert Haas
Дата:
Сообщение: Re: SCRAM with channel binding downgrade attack