Re: Materialized views and unique indexes - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Materialized views and unique indexes
Date
Msg-id CAB7nPqR+GDZF9S80rmP5wK4dainVVEaa5igr7rD3uddKm4KLcQ@mail.gmail.com
Whole thread Raw
In response to Re: Materialized views and unique indexes  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Materialized views and unique indexes
List pgsql-hackers


On Fri, Mar 8, 2013 at 11:33 AM, Josh Berkus <josh@agliodbs.com> wrote:

> As expected, the refresh failed, but the error message is not really
> user-friendly.
> Shouldn't we output instead something like that?
> ERROR: could not refresh materialized view because of failure when
> rebuilding index"
> DETAIL: key is duplicated.

Is there a good reason to allow unique indexes (or constraints in
general) on matviews?
Don't think so. It would make sense to block the creation of all the constraints on matviews.
 
Just based on the docs, matviews cannot have constraints:
http://www.postgresql.org/docs/devel/static/sql-altermaterializedview.html

Now that you mention it, you can create constraints on them (code at c805659).
postgres=# create table aa (a int);
CREATE TABLE
postgres=# create materialized view aam as select * from aa;
SELECT 0
postgres=# alter materialized view aam add constraint popo unique(a);
ALTER MATERIALIZED VIEW
postgres=# \d aam
Materialized view "public.aam"
 Column |  Type   | Modifiers
--------+---------+-----------
 a      | integer |
Indexes:
    "popo" UNIQUE CONSTRAINT, btree (a)

Also, as it is not mandatory for a unique index to be a constraint, I think that we should block the creation of unique indexes too to avoid any problems. Any suggestions?
--
Michael

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Materialized views and unique indexes
Next
From: Craig Ringer
Date:
Subject: Re: Materialized views and unique indexes