Re: Materialized views WIP patch - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Materialized views WIP patch
Date
Msg-id 1361200714.37038.YahooMailNeo@web162904.mail.bf1.yahoo.com
Whole thread Raw
In response to Re: Materialized views WIP patch  (Thom Brown <thom@linux.com>)
List pgsql-hackers
Thom Brown <thom@linux.com> wrote:
> On 16 February 2013 01:01, Kevin Grittner <kgrittn@ymail.com> wrote:
>> Unless something else comes up in review or I get feedback to
>> the contrary I plan to deal with the above-mentioned issues and
>> commit this within a week or two.
>
> At the moment it's not possible to rename a column without using
> ALTER TABLE on an MV.
>
> Also, shouldn't we have the ability to set the collation on a
> column of the MV?

Will fix.

> And the inconsistency between regular views and MVs is still
> present, where MVs always dump with column parameters in their
> definition, and views never do.  Not a show-stopper, but curious
> nonetheless.

I haven't worried about this because current behavior generates
correct results -- this seems like a micro-optimization.  The
explanation for why it wound up that way is that creating a
materialized view is in many ways more like creating a table than
like creating a view -- it seemed safer and less invasive to modify
the CREATE TABLE code than the CREATE VIEW code, and specifying
column names just fell out of that as part of the minimal change.
In looking at the pg_dump output, though, I see that the CMV AS
clause also is getting the names right with column-level aliases,
so it should be pretty simple and safe to leave off the
column-list section for MVs.  I guess it's worth it just to
forestall further questions on the topic.

Thanks!

-Kevin



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Materialized views WIP patch
Next
From: Merlin Moncure
Date:
Subject: Re: JSON Function Bike Shedding