From: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
---|---|
To: | Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Commitfest 2021-11 Patch Triage - Part 1 |
Date: | 2021-12-03 06:52:22 |
Message-ID: | 20211203155222.60013e97ae635ef5c66fda39@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 1 Dec 2021 09:14:31 -0300
Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> wrote:
> >
> > I think the reason why we can't update a materialized view directly is
> > because
> > it is basically a "view" and it should not contains any data irrelevant to
> > its
> > definition and underlying tables. If we would have a feature to update a
> > materialized view direcly, maybe, it should behave as updatable-view as
> > well
> > as normal (virtual) views, although I am not sure....
> >
>
> Well, I didn´t find any place where is detailed why those tables are not
> updatable.
> And would be fine to be updated through triggers or cron jobs until IVM is
> available.
> CheckValidRowMarkRel just gives an exception "cannot lock rows in
> materialized view ...", but why ?
> What are the differences between Materialized Views and tables ?
It would be that materialized views are related to its definition query
and expected to have contents that is consistent with it, at least at some
point in time, I think.
In order to allow triggers to update materialized views, we'd need to
make OpenMatViewIncrementalMaintenance and CloseMatViewIncrementalMaintenance
public since there are static functions in matview.c. However, there is a
concern that it will make the contents of a materialized view completely
unreliable [1]. Therefore, if we do it, we would need privilege management
in some way.
Regards,
Yugo Nagata
--
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-12-03 06:55:32 | Re: Use simplehash.h instead of dynahash in SMgr |
Previous Message | Masahiko Sawada | 2021-12-03 06:41:47 | Re: Skipping logical replication transactions on subscriber side |