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 |
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 |
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 |