| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| 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-06 19:10:07 |
| Message-ID: | 660576.1623006607@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2021-06-08 05:31:55 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
| Previous Message | Tom Lane | 2021-06-06 16:38:26 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2021-06-06 19:13:17 | Re: PoC/WIP: Extended statistics on expressions |
| Previous Message | Peter Geoghegan | 2021-06-06 19:03:53 | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |