> > > 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.
