Ian,
> Thanks! I would have, but my messages bounce from SQL, even though I am
subscribed ( I get the messages, for crying out loud!)
send an e-mail to [EMAIL PROTECTED]
>
> PS RECORD doesn't work but I think that is because I am on 7.2.1
OK. I may have tested that on 7.4 devel by acci
Ian,
You're welcome. Replying to the list for the edification of other users.
-Josh
> I just figgered it out. I declared the function as
>
> create function some_func(test) returns int ...
>
> where test is the name of a table. The values are passed as a tcl array. I
will see if RECORD w
Ian,
> Anyway, I have a similar requirement, to intercept insert/update/delete and
redirect the data if a condition is met. Right now I am trying an INSTEAD
rule that puts the condtion in the WHERE of the rule definition. It seems to
work OK, but if the condition has exeptions where I would
Josh,
Thanks for the info.
I need to change an insert into an update when the key already exists.
I have been using a rules to test it on a small set (table) and it
works.
"Rules can't use indexes" just scared me. I will have to test on a
larger set.
Also, I had the impression that if a trigger
Bruce Momjian wrote:
> > > > 3) There are no AFTER Rules, making, for example, a rule with a table
> > check on
> > > > the new data impractical, so you'd want to use Triggers or Constraints
> > >
> > > We have changed ordering in 7.3 where I think INSERT rules are _after_
> > > the insert.
> >
Josh Berkus wrote:
>
> Bruce,
>
> > > 1) Rules can't use indexes to do their processing, so Rules which query
> large
> > > secondary tables can be a bad idea (maybe this has changed?)
> >
> > I don't think this is true. Rewrite is before optimizer so it should be
> > optimized just the same.
Bruce,
> > 1) Rules can't use indexes to do their processing, so Rules which query
large
> > secondary tables can be a bad idea (maybe this has changed?)
>
> I don't think this is true. Rewrite is before optimizer so it should be
> optimized just the same.
I was speaking if the Rule has to d
Josh Berkus wrote:
>
> Bruce, Richard,
>
> > Triggers are mostly for testing/modifying the row being
> > inserted/updated, while rules are better for affecting other rows or
> > other tables.
>
> Hmmm. Thought that there were also some other criteria:
>
> 1) Rules can't use indexes to do their
Bruce, Richard,
> Triggers are mostly for testing/modifying the row being
> inserted/updated, while rules are better for affecting other rows or
> other tables.
Hmmm. Thought that there were also some other criteria:
1) Rules can't use indexes to do their processing, so Rules which query large
No, the rule will affect all the rows using one query.
---
Jean-Luc Lachance wrote:
> Thanks for the info.
>
> Do you mean that if an update affects more than one row I should use
> triggers because the rules will be execut
Thanks for the info.
Do you mean that if an update affects more than one row I should use
triggers because the rules will be executed only once?
JLL
Richard Huxton wrote:
>
> On Friday 06 Dec 2002 4:03 pm, Jean-Luc Lachance wrote:
> > Hi all!
> >
> > Is there a guideline on the use of rules co
My book has a section on that:
http://www.postgresql.org/docs/awbook.html
Triggers are mostly for testing/modifying the row being
inserted/updated, while rules are better for affecting other rows or
other tables.
Jean-Luc Lachance wrote:
> Hi all!
>
> Is there a guideline on the use of
On Friday 06 Dec 2002 4:03 pm, Jean-Luc Lachance wrote:
> Hi all!
>
> Is there a guideline on the use of rules compared to triggers when both
> can be use to achieve the same result?
If I can use rules I do. Rules rewrite the query so are processed once,
whereas triggers get processed for every r
Hi all!
Is there a guideline on the use of rules compared to triggers when both
can be use to achieve the same result?
JLL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
14 matches
Mail list logo
