From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Amit kapila <amit(dot)kapila(at)huawei(dot)com>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proof of concept: auto updatable views [Review of Patch] |
Date: | 2012-11-08 20:29:22 |
Message-ID: | CAEZATCUiCGJXh5NNbOJhc_uhFRz5jjzEJrH4btsjt=ZV5N8Fzg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8 November 2012 19:29, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
>> On 8 November 2012 17:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I believe that the right way to think about the auto-update
>>> transformation is that it should act like a supplied-by-default
>>> unconditional INSTEAD rule.
>
>> But if you treat the auto-update transformation as a
>> supplied-by-default unconditional INSTEAD rule, and the user defines
>> their own conditional INSTEAD rule, if the condition is true it would
>> execute both the conditional rule action and the auto-update action,
>> making it an ALSO rule rather than the INSTEAD rule the user
>> specified.
>
> Well, that's how things work if you specify both a conditional and an
> unconditional INSTEAD action, so I don't find this so surprising.
>
To me, it's very surprising, so I must be thinking about it
differently. I think that I'm really expecting auto-updatable views to
behave like tables, so I keep coming back to the question "what would
happen if you did that to a table?".
Taking another concrete example, I could use a conditional DO INSTEAD
NOTHING rule on a table to prevent certain values from being inserted:
create table foo(a int);
create rule foo_r as on insert to foo where new.a < 0 do instead nothing;
insert into foo values(-1),(1);
select * from foo;
a
---
1
(1 row)
So I would expect the same behaviour from an auto-updatable view:
create table bar(a int);
create view bar_v as select * from bar;
create rule bar_r as on insert to bar_v where new.a < 0 do instead nothing;
insert into bar_v values(-1),(1);
select * from bar_v;
a
---
1
(1 row)
Having that put both -1 and 1 into bar seems completely wrong to me.
I could live with it raising a "you need an unconditional instead
rule" error, but that makes the auto-update view seem a bit
half-baked.
This also seems like a much more plausible case where users might have
done something like this with a trigger-updatable view, so I don't
think the backwards-compatibility argument can be ignored.
Regards,
Dean
> What you're arguing for would make some sense if the auto-update feature
> could be seen as something that acts ahead of, and independently of,
> INSTEAD rules and triggers. But it can't be treated that way: in
> particular, the fact that it doesn't fire when there's an INSTEAD
> trigger pretty much breaks the fiction that it's an independent
> feature. I would rather be able to explain its interaction with rules
> by saying "it's a default implementation of an INSTEAD rule" than by
> saying "well, it has these weird interactions with INSTEAD rules, which
> are different for conditional and unconditional INSTEAD rules".
>
> Or we could go back to what I suggested to start with, which is that the
> auto-update transformation doesn't fire if there are *either*
> conditional or unconditional INSTEAD rules. That still seems like the
> best way if you want an arms-length definition of behavior; it means we
> can explain the interaction with INSTEAD rules exactly the same as the
> interaction with INSTEAD triggers, ie, having one prevents the
> transformation from being used.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2012-11-08 20:36:23 | AutoVacuum starvation from sinval messages |
Previous Message | Simon Riggs | 2012-11-08 19:51:01 | Re: TRUNCATE SERIALIZABLE and frozen COPY |