Kevin Grittner <kgri...@ymail.com> writes:
> In working up a patch for this approach, I see that if CREATE
> FOREIGN TABLE is executed with default_with_oids set to true, it
> adds an oid column which appears to be always zero in my tests so
> far (although maybe other FDWs support it?). Do we want to leave
> that alone? If we're going to add code to ignore that setting for
> matviews do we also want to ignore it for FDWs?
I don't see any very good reason for the core code to be assuming
anything about whether an FDW will support OIDs or not. It would have
been noticeably more painful to get postgres_fdw's writable-table
support working if the core code had tried to enforce an opinion that
foreign tables couldn't have ctid, to take something somewhat
comparable.
Where I'd like to see things going is to add a hook for FDWs to control
what system columns get created for their tables. When that happens,
an FDW could throw error about OIDs if it wants to. In the meantime
I don't feel a need to change the behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
