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

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Petr Fedorov <petr(dot)fedorov(at)phystech(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Date: 2021-06-08 05:31:55
Message-ID: 20210608053155.GB444080@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Sun, Jun 06, 2021 at 03:10:07PM -0400, Tom Lane wrote:
> I wrote:
> > We could make use of COMPARE_COERCIONFORM_FIELD 100% correct by removing
> > these two tests of the funcformat value, but on the whole I doubt that
> > would be better.
>
> On still closer inspection, that seems like it'd be fine. All of
> the gram.y productions that emit COERCE_SQL_SYNTAX also produce
> schema-qualified function names (via SystemFuncName); and it seems
> hard to see a use-case where we'd not do that. This makes the two
> checks I cited 100% redundant, because the conditions they are in
> also insist on an unqualified function name. So let's just take them
> out again, making it strictly OK to use COMPARE_COERCIONFORM_FIELD.

I have little intuition on this exact topic, but I have no particular concerns
about the change you pushed.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-06-08 07:49:25 BUG #17050: cursor with for update + commit in loop
Previous Message Tom Lane 2021-06-06 19:10:07 Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2021-06-08 05:43:58 Re: Race condition in recovery?
Previous Message Kyotaro Horiguchi 2021-06-08 05:09:28 Re: Logical replication keepalive flood