Re: BUG #15287: postgres_fdw: the "WHERE date_trunc('day', dt) = 'YYYY-MM-DD' does not push to remote. - Mailing list pgsql-bugs

From Andrew Gierth
Subject Re: BUG #15287: postgres_fdw: the "WHERE date_trunc('day', dt) = 'YYYY-MM-DD' does not push to remote.
Date
Msg-id 87effxizux.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: BUG #15287: postgres_fdw: the "WHERE date_trunc('day', dt) = 'YYYY-MM-DD' does not push to remote.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #15287: postgres_fdw: the "WHERE date_trunc('day', dt) ='YYYY-MM-DD' does not push to remote.  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: BUG #15287: postgres_fdw: the "WHERE date_trunc('day', dt) = 'YYYY-MM-DD' does not push to remote.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom> Alternatively, if postgres_fdw could know which functions don't
 Tom> really pay attention to their input collation, it could skip this
 Tom> check for those functions. But that's not an easy thing to fix
 Tom> either.

Wild idea: we have quite a few functions (e.g. date_trunc, date_part,
timezone, encode, decode, make_timestamptz, plus various extension
functions such as in pgcrypto) that take a "text" parameter which is
nothing more than a poor-man's enum, or otherwise represents something
which isn't actually free text. Perhaps these should use "name" instead,
or in some cases an enum type?

(or in the case of date_trunc and extract, maybe they need to be split
up into separate functions so that we can properly distinguish the
immutable from the mutable cases)

-- 
Andrew (irc:RhodiumToad)


pgsql-bugs by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: BUG #15287: postgres_fdw: the "WHERE date_trunc('day', dt) = 'YYYY-MM-DD' does not push to remote.
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #15287: postgres_fdw: the "WHERE date_trunc('day', dt) ='YYYY-MM-DD' does not push to remote.