From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Updatable views |
Date: | 2008-05-08 13:24:18 |
Message-ID: | 2DB55D3BC1B317D2B98905FC@imhotep.credativ.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
--On Donnerstag, Mai 08, 2008 13:28:14 +0100 Simon Riggs
<simon(at)2ndquadrant(dot)com> wrote:
> On Thu, 2008-05-08 at 13:48 +0200, Bernd Helmle wrote:
>> --On Mittwoch, Mai 07, 2008 20:38:59 +0100 Simon Riggs
>> <simon(at)2ndquadrant(dot)com> wrote:
>>
>> >> Where are we on this feature?
>> >
>> > Any update, Bernd?
>>
>> I've merged the patch into current -HEAD and updated some parts. My
>> current *working* state can be reviewed at
>>
>> <http://git.postgresql.org/?p=~psoo/postgresql.git;a=shortlog;h=updatabl
>> e_views>
>>
>> I'm still not sure how to implement a reliable CHECK OPTION, but short
>> on time i haven't done a very deep investigation yet. Next idea was to
>> look at the updatable cursor stuff, maybe something there can be reused.
>
> Your earlier patch seemed to add two rules if the view had a with check
> option? One with a pass through and another one with a do-nothing and a
> where clause.
>
> As I understand it
>
> CREATE VIEW x AS SELECT * FROM foo WHERE where-clause WITH CHECK OPTION
>
> should generate an INSERT rule like this
>
> CREATE RULE somename AS ON INSERT TO x WHERE where-clause DO INSERT ...
>
This was indeed the implementation i've proposed. We have rejected this
idea then because it doesn't work with volatile functions reliable due to
double evaluation:
<http://archives.postgresql.org/pgsql-patches/2006-08/msg00483.php>
Tom's example even demonstrates a serious constraint in rule based updates,
since you get side effects in such conditions you won't expect, even
without a CHECK OPTION.
> which seems straightforward, no?
>
> The SQLStandard default is CASCADED and it seems easier not to worry too
> much about the LOCAL option until we have the basics working. I'm not
> even sure that we *want* the LOCAL option anyway having read what it
> means, plus it isn't supported by many other DBMS.
>
> Do you store anything in the catalog to mark the view as updatable or
> not? I couldn't see that but it seemed easier than trying to resolve all
> of the updatability characteristics at run-time.
I'm not sure want you mean, but pg_rewrite.ev_kind stores the nature of the
rule. Updatability is determined by the checkTree() function internally.
It's easy to query pg_rewrite to examine wether a view is updatable or not.
>
> I may be able to help some with the patch, if you'd like?
>
You're welcome ;)
> --
> Simon Riggs
> 2ndQuadrant http://www.2ndQuadrant.com
--
Thanks
Bernd
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-05-08 13:38:30 | Re: Internal design of MERGE, with Rules |
Previous Message | Peter Eisentraut | 2008-05-08 12:56:57 | Re: Updatable views |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-05-08 13:42:50 | Re: Updatable views |
Previous Message | Peter Eisentraut | 2008-05-08 12:56:57 | Re: Updatable views |