> 1. Is there any plans to add "non-strict mode" (configurable via options on > server/table/column level) to allow pushing down conditions for all data > types?
No. You might as well call it a "return random answers" mode.
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.
> 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?
Same problem. We don't have any way of knowing whether type foo on the 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.
