Re: Materialized view assertion failure in HEAD

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Materialized view assertion failure in HEAD
Дата
Msg-id 1363819255.86513.YahooMailNeo@web162902.mail.bf1.yahoo.com
обсуждение исходный текст
Ответ на Re: Materialized view assertion failure in HEAD  (Kevin Grittner <kgrittn@ymail.com>)
Ответы Re: Materialized view assertion failure in HEAD  (Kevin Grittner <kgrittn@ymail.com>)
Re: Materialized view assertion failure in HEAD  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Kevin Grittner <kgrittn@ymail.com> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:

>> It seems to me that the right place to fix this is in
>> interpretOidsOption(), by returning false rather than
>> default_with_oids whenever the relation is a materialized view.

> I like it.

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?

[ thinks... ]

I suppose I should post a patch which preserves the status quo for
FDWs and treat that as a separate issue.  So, rough cut attached.
Obviously some docs should be added around this, and I still need
to do another pass to make sure I didn't miss anything; but it
passes make world-check, make installworld-check, and the
regression database can be dumped and loaded without problem.

Comments?

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Let's invent a function to report lock-wait-blocking PIDs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Let's invent a function to report lock-wait-blocking PIDs