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

<div dir="ltr">CREATE MATERIALIZED VIEW statement ends up being CREATE TABLE AS statement underneath with table type
matview.In that case, why don't I see special treatment only for materialized view and not CTAS in general, which
allowscolumn names to specified like the case in the bug reported.<br /></div><div class="gmail_extra"><br /><br /><div
class="gmail_quote">OnFri, Nov 1, 2013 at 3:52 AM, Kevin Grittner <span dir="ltr"><<a
href="mailto:kgrittn@ymail.com"target="_blank">kgrittn@ymail.com</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"<a
href="mailto:t.katsumata1122@gmail.com">t.katsumata1122@gmail.com</a>"<<a
href="mailto:t.katsumata1122@gmail.com">t.katsumata1122@gmail.com</a>>wrote:<br /><br /> > I'm testing the
MaterializedView.<br /> > When I've tried to create materialized view with specified<br /> > column_name, I got
anERROR.<br /> ><br /> > example:<br /> > - Creating original table<br /> > CREATE TABLE t ( i int );<br />
><br/> > - Creating materialized view with column_name<br /> > CREATE MATERIALIZED VIEW mv_t(ii) AS SELECT *
FROMt;<br /> ><br /> > And then, I got a bellow ERROR.<br /> > ----<br /> > ERROR:  SELECT rule's target
entry1 has different column name from "ii"<br /> > ----<br /> ><br /> > I did not get any ERROR with non
materializedview.<br /> > CREATE VIEW mv_t(ii) AS SELECT * FROM t;<br /> ><br /> > Is this a bug or
restrictionfor Materialized View?<br /><br /> It's a bug.  Will fix in the next 9.3 minor release.<br /><br /> Moving
thediscussion to the -hackers list to discuss the fix.<br /><br /> This bug was introduced in
fb60e7296c2cf15195802b4596496b179bdc905a<br/> based on this feedback:<br /><br /><a
href="http://www.postgresql.org/message-id/20600.1363022702@sss.pgh.pa.us"
target="_blank">http://www.postgresql.org/message-id/20600.1363022702@sss.pgh.pa.us</a><br/><br /> I picked the wrong
responseto that feedback.  Attached is a patch<br /> which fixes things along the alternative lines suggested.  This<br
/>includes a regression test to ensure that this doesn't get broken<br /> again.<br /><br /> If there are no objections
I'llapply this within a few days.<br /><br /> --<br /> Kevin Grittner<br /> EDB: <a href="http://www.enterprisedb.com"
target="_blank">http://www.enterprisedb.com</a><br/> The Enterprise PostgreSQL Company<br /><br /> --<br /> Sent via
pgsql-hackersmailing list (<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br /> To
makechanges to your subscription:<br /><a href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/><br /></blockquote></div><br /><br clear="all"
/><br/>-- <br /><div dir="ltr">Best Wishes,<br />Ashutosh Bapat<br />EnterpriseDB Corporation<br />The Postgres
DatabaseCompany<br /></div></div>