Re: [PATCHES] Updatable views

From: Bernd Helmle <bernd(dot)helmle(at)oopsware(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [PATCHES] Updatable views
Date: 2006-09-01 12:31:51
Message-ID: B5B0D8CF2BF52202EE6F1F3D@[172.26.14.247]
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

--On Donnerstag, August 31, 2006 11:10:47 -0400 Tom Lane
<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> The problem is not with the view condition. Consider
>
> CREATE TABLE data (id serial primary key, ...);
>
> CREATE VIEW only_new_data AS SELECT * FROM data WHERE id > 12345
> WITH CHECK OPTION;
>
> INSERT INTO only_new_data VALUES(nextval('data_id_seq'), ...);
>
> The proposed implementation will execute nextval twice (bad), and will
> apply the WITH CHECK OPTION test to the value that isn't the one stored
> (much worse). It doesn't help if the id is defaulted.

*scratches head*....i don't see a shortcoming solution for this in my
current implementation,
indeed. I admit that this is a serious containment of updatable views in
its current
incarnation (at least for the check option).

*thinking*
I would like to try to grab your idea to push down the CHECK OPTION logic
down to the executor as a (table/view?) constraint. Would that be an idea
worth to consider and,
most important, is this doable? I don't have that much experience in the
executor, so i fear
this isn't something that will be done within a week or so.....:(

--
Thanks

Bernd

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2006-09-01 13:16:45 DOC: catalog.sgml
Previous Message Paul B. Anderson 2006-09-01 12:02:24 Vacuum error on database postgres