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

From Kevin Grittner
Subject Re: Materialized view assertion failure in HEAD
Date
Msg-id 1363819255.86513.YahooMailNeo@web162902.mail.bf1.yahoo.com
Whole thread Raw
In response to Re: Materialized view assertion failure in HEAD  (Kevin Grittner <kgrittn@ymail.com>)
Responses 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>)
List 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
Attachment

pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Let's invent a function to report lock-wait-blocking PIDs
Next
From: Tom Lane
Date:
Subject: Re: Let's invent a function to report lock-wait-blocking PIDs