Skip site navigation (1) Skip section navigation (2)

Re: WIP: Automatic view update rules

From: "Bernd Helmle" <bernd(at)oopsware(dot)de>
To: "Jaime Casanova" <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: "Bernd Helmle" <mailings(at)oopsware(dot)de>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: Automatic view update rules
Date: 2008-12-28 14:29:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> On Mon, Dec 22, 2008 at 8:53 AM, Bernd Helmle <mailings(at)oopsware(dot)de>
> wrote:
>> --On Mittwoch, November 26, 2008 10:54:01 +0100 Bernd Helmle
>> <mailings(at)oopsware(dot)de> wrote:
>> Okay, i've finally managed to create an updated version with (hopefully)
>> all
>> issues mentioned by Robert adressed.
> Hi Bernd,
> 1) i found a crash type bug, try this:
> create table foo (
>     id  integer     not null    primary key,
>     name    varchar(30)
> ) with oids;
> create view foo_view as select oid, * from foo;
> with this you will get an error like this one:
> ERROR:  RETURNING list's entry 1 has different type from column "oid"

Hrm, seems i've introduced a bug while implementing RETURNING support.

> but if you make this:
> alter table foo add column description text;
> create view foo_view as select oid, * from foo;
> then, the server crash.
> STATEMENT:  create or replace view v_foo as select oid, * from foo;
> LOG:  server process (PID 16320) was terminated by signal 11: Segmentation
> fault
> LOG:  terminating any other active server processes
> maybe the better solution is to not allow such a view to be updatable

Yes, it seems we have to check for target lists having negative attnums in
checkTree(). Another solution would be to simply ignore those columns
(extract them from the target list and include all updatable columns

> 2) Another less important bug, the WITH CHECK OPTION is accepted even
> when that functionality is not implemented.
> updatable_views=# create or replace view v2 as select * from foo where
> id < 10 with check option;
> NOTICE:  CREATE VIEW will create implicit INSERT/UPDATE/DELETE rules

What do we want in this case? We can throw an error telling that CHECK
OPTION isn't supported yet or simply issueing a warning.

> 3) one final point: seems like you'll have to update the rules
> regression test (attached the regression.diffs)


Thanks for the review so far.


In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2008-12-28 14:47:47
Subject: Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets
Previous:From: Hitoshi HaradaDate: 2008-12-28 07:22:28
Subject: Re: Windowing Function Patch Review -> Standard Conformance

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group