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 1363977106.98516.YahooMailNeo@web162903.mail.bf1.yahoo.com
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> wrote:
> 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?

Tidied up, further tested, and pushed.

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Ants Aasma
Date:
Subject: Re: Enabling Checksums
Next
From: Kevin Grittner
Date:
Subject: dump, restore, dump yields differences