Re: Materialized view assertion failure in HEAD - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Materialized view assertion failure in HEAD
Date
Msg-id 29061.1363981650@sss.pgh.pa.us
Whole thread Raw
In response to Re: Materialized view assertion failure in HEAD  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
Kevin Grittner <kgrittn@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)
Next
From: Tom Lane
Date:
Subject: Re: Page replacement algorithm in buffer cache