Re: Materialized view assertion failure in HEAD

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Materialized view assertion failure in HEAD
Дата
Msg-id 29061.1363981650@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Materialized view assertion failure in HEAD  (Kevin Grittner <kgrittn@ymail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Page replacement algorithm in buffer cache