Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Дата
Msg-id 5752.1590424827@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost whenextracting epoch  (Vik Fearing <vik@postgresfriends.org>)
Ответы Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost whenextracting epoch  (Vik Fearing <vik@postgresfriends.org>)
Список pgsql-hackers
Vik Fearing <vik@postgresfriends.org> writes:
> On 5/25/20 3:28 PM, Peter Eisentraut wrote:
>> I looked into this (changing the return types of date_part()/extract()
>> from float8 to numeric).

> I think what would be better is to have a specific date_part function
> for each part and have extract translate to the appropriate one.

Doesn't really work for upwards compatibility with existing views,
which will have calls to date_part(text, ...) embedded in them.

Actually, now that I think about it, changing the result type of
date_part() is likely to be problematic anyway for such cases.
It's not going to be good if pg_upgrade's dump/restore of a view
results in a new output column type; especially if it's a
materialized view.

So maybe what we'd have to do is leave date_part() alone for
legacy compatibility, and invent new functions that the extract()
syntax would now be translated to.  While at it, maybe we could
fix things so that the syntax reverse-lists the same way instead
of injecting Postgres-isms...

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vik Fearing
Дата:
Сообщение: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost whenextracting epoch
Следующее
От: Vik Fearing
Дата:
Сообщение: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost whenextracting epoch