--On Donnerstag, August 31, 2006 11:10:47 -0400 Tom Lane <[EMAIL PROTECTED]> 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).

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.....:(



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to