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 6816.1590426450@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 when extracting epoch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Vik Fearing <vik@postgresfriends.org> writes:
> On 5/25/20 6:40 PM, Tom Lane wrote:
>> While at it, maybe we could
>> fix things so that the syntax reverse-lists the same way instead
>> of injecting Postgres-isms...

> I'm not sure what this means.

This:

regression=# create view myview as select extract(year from current_timestamp) as y;
CREATE VIEW
regression=# \d+ myview
...
View definition:
 SELECT date_part('year'::text, CURRENT_TIMESTAMP) AS y;

What had been a 100% spec-compliant view definition is now quite
Postgres-specific.  I fixed some similar problems in 0bb51aa96 (before
that, the CURRENT_TIMESTAMP part would've reverse-listed differently
too); but I didn't tackle EXTRACT(), SUBSTRING(), and other cases.

I'm not claiming that we really need to fix all of those.  But if we are
going to pick nits about which data type EXTRACT() returns then I think
it's legit to worry about its reverse-list representation at the same
time ... especially if we must touch the grammar's translation anyway.

            regards, tom lane



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

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