> > If we did not define
> > it that way, I think your example would have to error out --- how
> > would you choose which INSTEAD rule wins?
>
> The documentation says that they evaluate in alphabetical order by
> name. So I would expect that the first one to have its WHERE statement
> evaluate
On Apr 26, 2005, at 5:02 PM, Jan Wieck wrote:
The multi-action rules usually come into play when someone attempts to
make join-views updatable. Not an easy problem, granted, but most of
the time I have found a combination of rules together with ON
UPDATE/DELETE CASCADE constraints or even user d
On 4/26/2005 5:58 PM, Tom Lane wrote:
David Wheeler <[EMAIL PROTECTED]> writes:
No, you can have multiple queries--you just have to understand that
those that come first might have an effect on those that come later.
... which indeed can be a feature, not a bug, depending on what you're
doing ...
On Apr 26, 2005, at 2:58 PM, Tom Lane wrote:
... which indeed can be a feature, not a bug, depending on what you're
doing ...
Absolutely. An INSERT rule I have looks like this:
CREATE RULE insert_one AS
ON INSERT TO one WHERE NEW.id IS NULL
DO INSTEAD (
INSERT INTO _simple (id, guid, state, name,
David Wheeler <[EMAIL PROTECTED]> writes:
> No, you can have multiple queries--you just have to understand that
> those that come first might have an effect on those that come later.
... which indeed can be a feature, not a bug, depending on what you're
doing ...
regards,
Rob Butler <[EMAIL PROTECTED]> writes:
> For this particular scenario, can't you just create
> two ON DELETE rules? The first would delete from b,
> the second from a. Perhaps an example with a scenario
> like this can be added to the doc's?
No, that doesn't work any more than the other way.
On Apr 26, 2005, at 2:43 PM, Rob Butler wrote:
For this particular scenario, can't you just create
two ON DELETE rules? The first would delete from b,
the second from a. Perhaps an example with a scenario
like this can be added to the doc's?
No, that approach has the same problem. Once the first
For this particular scenario, can't you just create
two ON DELETE rules? The first would delete from b,
the second from a. Perhaps an example with a scenario
like this can be added to the doc's?
So, the short answer is you can only perform one query
in a rule, but you can have multiple rules de
On Apr 26, 2005, at 11:20 AM, Tom Lane wrote:
The problem is that OLD is effectively a macro for the view, and once
you've deleted one of the rows, that ID is no longer present anywhere
in
the view. Sometimes you can work around this by making the join an
outer join, but that's certainly a kluge.
On Apr 26, 2005, at 12:35 PM, Tom Lane wrote:
One possibility for an alternative mechanism is to allow triggers on
views --- but I'm not sure exactly how this would work, or if it would
solve all the problems. At the very least it would answer the "data
stability" issue, since I suppose the trigge
Jan Wieck <[EMAIL PROTECTED]> writes:
> On 4/26/2005 3:01 PM, Rob Butler wrote:
>> Are rules even needed anymore? Can't you do this all
>> with triggers? If you want to "DO INSTEAD" just use a
>> row based trigger, and return null. Or is this less
>> efficient?
> On INSERT, yes, on UPDATE, how
On 4/26/2005 3:01 PM, Rob Butler wrote:
Are rules even needed anymore? Can't you do this all
with triggers? If you want to "DO INSTEAD" just use a
row based trigger, and return null. Or is this less
efficient?
On INSERT, yes, on UPDATE, how so?
Jan
Later
Rob
--- David Wheeler <[EMAIL PROTECTED]>
Are rules even needed anymore? Can't you do this all
with triggers? If you want to "DO INSTEAD" just use a
row based trigger, and return null. Or is this less
efficient?
Later
Rob
--- David Wheeler <[EMAIL PROTECTED]> wrote:
> On Apr 26, 2005, at 8:55 AM, Tom Lane wrote:
>
> > Well, they handl
David Wheeler <[EMAIL PROTECTED]> writes:
> On Apr 26, 2005, at 8:55 AM, Tom Lane wrote:
>> Well, they handle simple situations OK, but we keep seeing people get
>> burnt as soon as they venture into interesting territory.
> [ snip ]
> Ah, yes, you're right, that is...unexpected. Perhaps OLD can
On Apr 25, 2005, at 11:00 PM, Tom Lane wrote:
DO INSTEAD means that the *original* query will not execute; it does
not suppress actions produced by other rules.
Ah!
If we did not define
it that way, I think your example would have to error out --- how
would you choose which INSTEAD rule wins?
The d
On Apr 25, 2005, at 11:37 PM, Tom Lane wrote:
(I have been thinking more and more that we should consider a wholesale
redesign of the rule mechanism, because it sure seems not to answer the
needs/expectations of a lot of people out there. But I am not talking
about marginal questions like what INS
On Apr 26, 2005, at 8:55 AM, Tom Lane wrote:
Well, they handle simple situations OK, but we keep seeing people get
burnt as soon as they venture into interesting territory. For
instance,
if the view is a join, you can't easily make a rule that turns a delete
into deletions of both joined rows. A
David Wheeler <[EMAIL PROTECTED]> writes:
> On Apr 25, 2005, at 11:37 PM, Tom Lane wrote:
>> (I have been thinking more and more that we should consider a wholesale
>> redesign of the rule mechanism, because it sure seems not to answer the
>> needs/expectations of a lot of people out there.
> I th
Tom Lane wrote:
Here I've got to differ. The alphabetical-order rule was introduced to
nail down the order of execution of operations that were going to happen
in any case, but would otherwise have happened in an unspecified order.
You are proposing to let it define what gets executed and what doe
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> DO INSTEAD means that the *original* query will not execute; it does
>> not suppress actions produced by other rules.
> I think DO INSTEAD should control whether the original query is added to
> the set of query trees produced by the ru
Tom Lane wrote:
DO INSTEAD means that the *original* query will not execute; it does
not suppress actions produced by other rules. If we did not define
it that way, I think your example would have to error out --- how
would you choose which INSTEAD rule wins?
I think DO INSTEAD should control whet
Neil Conway <[EMAIL PROTECTED]> writes:
> Note that although both rules are DO INSTEAD, they both get fired for
> the insertion.
DO INSTEAD means that the *original* query will not execute; it does
not suppress actions produced by other rules. If we did not define
it that way, I think your examp
I find the following behavior confusing:
neilc=# create table t1 (a int, b int);
CREATE TABLE
neilc=# create table t2 (a int, b int);
CREATE TABLE
neilc=# create table t3 (a int, b int);
CREATE TABLE
neilc=# create rule t1_rule1 as on insert to t1 where NEW.a > 100 do
instead insert into t2 values
23 matches
Mail list logo
