Re: rules: evaluate inputs in advance

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Markus Schiltknecht <markus(at)bluegap(dot)ch>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: rules: evaluate inputs in advance
Date: 2006-05-12 16:05:48
Message-ID: 20060512160548.GG12955@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, May 12, 2006 at 04:22:00PM +0200, Markus Schiltknecht wrote:
> > There have been discussions about the problems
>
> Do you have some pointers here? I did not find relevant discussions in
> the archives (of gmane.org)

Hmm, maybe not so much discussions as comments from developers when the
Nth problem with rules comes in a week. I remember a few but can't find
them in the archives.

In cases where rules work well, like views, they work really well. And
for simple updatable views they work too. But when you try to do
something complex you get hung up on things like nextval() being
evaluated multiple times.

I seem to remember Tom suggesting that for updatable views it'd
probably be nicer to be able to work it via an interface that looks
more like triggers. That way it would be clearer and you don't suffer
the problems related to multiple evaluations of parameters.
Unfortunatly, I havn't come up with something that could work.

> As far as I know, the rewriter simply copies plan tree nodes. I thought
> about inserting an 'evaluate-only-once' node which is linked from all
> rules and points to the expression to evaluate (instead of copying the
> complete explession and evaluating it several times in the executor).

But it can't really. In the example that started this thread, there are
two seperate rules and after rewriting the executor will be presented
two seperate queries. If you were dealing with only one row you could
change the second query to use currval() but that breaks if there are
more rows.

What you probably want is a function that is given the row and then
executes the two statements on a per row basis. This has the effect you
want but gives up the major benefit of rules, wholesale query
restructuring like views which allows the executor to find better
plans. The executor can't see inside a trigger so it can't optimise.

There are half-baked ideas, but I have no idea if they're better than
what we have now...

Have a ncie day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2006-05-12 16:06:57 Re: GUI Interface
Previous Message Dave Page 2006-05-12 16:00:23 Re: GUI Interface