| From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
| Cc: | "t(dot)katsumata1122(at)gmail(dot)com" <t(dot)katsumata1122(at)gmail(dot)com>, "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-01 08:20:50 |
| Message-ID: | 1383294050.11657.YahooMailNeo@web162904.mail.bf1.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> 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 allows column names to specified like the
> case in the bug reported.
While the initial population of the matview is a lot like CTAS (and
so far shares some code), the critical difference is that CTAS
doesn't store a rule to support repopulating the table. This issue
comes up in the validation of that rule for the matview.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | g.vanluffelen | 2013-11-01 10:38:28 | BUG #8573: int4range memory consumption |
| Previous Message | Kevin Grittner | 2013-11-01 08:16:47 | Re: [BUGS] BUG #8542: Materialized View with another column_name does not work? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2013-11-01 08:57:41 | Re: How should row-security affects ON UPDATE RESTRICT / CASCADE ? |
| Previous Message | Kevin Grittner | 2013-11-01 08:16:47 | Re: [BUGS] BUG #8542: Materialized View with another column_name does not work? |