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

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: BUG #15287: postgres_fdw: the "WHERE date_trunc('day', dt) ='YYYY-MM-DD' does not push to remote.
Дата
Msg-id CAMkU=1ydJ8pG-0Q_wrAVojDaPebQbCV5P2uZfj8ZtOiE1hUskw@mail.gmail.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>)
Ответы 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>)
Список pgsql-bugs
On Fri, Jul 20, 2018 at 2:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

However, that could only fix the OP's problem for these particular
functions, which are a small fraction of the ones we have that take
collatable types but don't really care about collation.  I kinda feel
like we should have invented an "ignores collation" function property,
so that such functions could be identified --- that would not only let
postgres_fdw handle this honestly, but we could refrain from throwing
unmatched-collations errors for cases where it doesn't really matter.
Maybe it's not too late to invent that in future.  If the parser sets
inputcollid = 0 for any function marked that way, then if the function is
incorrectly marked as ignoring collation it would get an error at runtime,
so it seems like we could add it safely.

Would this automatically apply to operators as well, like hstore's -> operator, once the fetchval function was marked?  The non-shippability of that can be a major problem.

Cheers,

Jeff

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

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15288: Logical Replication failed when inserting record whichhas CHECK constraint
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: LLVM jit and window functions on a temporary table