Re: [BUGS] BUG #8542: Materialized View with another column_name does not work?

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: "t(dot)katsumata1122(at)gmail(dot)com" <t(dot)katsumata1122(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] BUG #8542: Materialized View with another column_name does not work?
Date: 2013-11-04 20:53:32
Message-ID: 1383598412.78837.YahooMailNeo@web162901.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>
>> I am not sure that adding a boolean flag introducing a concept
>> related to matview inside checkRuleResultList is the best
>> approach to solve that. checkRuleResultList is something related
>> only to rules, and has nothing related to matviews in it yet.
>
> Well, I was tempted to keep that concept in DefineQueryRewrite()
> where the call is made, by calling  the new bool something like
> requireColumnNameMatch and not having checkRuleResultList()
> continue to use isSelect for that purpose at all.
> DefineQueryRewrite() already references RELKIND_RELATION once,
> RELKIND_MATVIEW twice, and RELKIND_VIEW three times, so it would
> hardly be introducing a new concept there.

Upon reflection, that seemed to be cleaner.  Pushed fix that way.
Not much of a change from the previously posted patch, but attached
here in case anyone wants to argue against this approach.

Thanks for the report!

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

Attachment Content-Type Size
matview-column-names-fix-v2.patch text/x-diff 5.2 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Kapila 2013-11-05 03:51:00 Re: [BUGS] BUG #8573: int4range memory consumption
Previous Message Tom Lane 2013-11-04 19:22:33 Re: [BUGS] BUG #8573: int4range memory consumption

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2013-11-04 21:44:57 Re: GIN improvements part 1: additional information
Previous Message Jeff Janes 2013-11-04 20:39:07 Re: Fast insertion indexes: why no developments