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
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 |