Re: postgres_fdw - push down conditionals for ENUMs
От | Sergiy Zuban |
---|---|
Тема | Re: postgres_fdw - push down conditionals for ENUMs |
Дата | |
Msg-id | CAGz8fGYAytw2Y-dKOV6mCnHQcRUBpo_buVKM1szAumzKBOFFKw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgres_fdw - push down conditionals for ENUMs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: postgres_fdw - push down conditionals for ENUMs
|
Список | pgsql-general |
> 1. Is there any plans to add "non-strict mode" (configurable via options onNo. You might as well call it a "return random answers" mode.
> server/table/column level) to allow pushing down conditions for all data
> types?
Its bad. I think most users would be happy to have "auto discovery" mode when foreign table fetches all required meta info to act like original table.
Same problem. We don't have any way of knowing whether type foo on the
> 2. There is an option that allows to map foreign table column to column
> with another name. What about adding another option to specify column type
> to be send to remote server?
remote end acts like foo locally
I understand it breaks all logic how FDW works internally, but I'm still trying to find some workaround to allow pushing down conditions for enums.
CREATE CAST (TEXT as STATUS_TYPE) WITH function to_status_type(text) AS IMPLICIT;
Could you please confirm such cast won't work because PostgreSQL converts ENUM values to INTs (enumtypid) on query rewriting stage, but casting works later, when data accessed?
I was thinking about looking up "enumtypid" in pg_enum by "enumlabel", but I couldn't find any way to force PostgreSQL to somehow use found enumtypid instead of original text.
В списке pgsql-general по дате отправления: