Re: rules: evaluate inputs in advance

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: rules: evaluate inputs in advance
Дата
Msg-id 20060512160548.GG12955@svana.org
обсуждение исходный текст
Ответ на Re: rules: evaluate inputs in advance  (Markus Schiltknecht <markus@bluegap.ch>)
Ответы Re: rules: evaluate inputs in advance  (Markus Schiltknecht <markus@bluegap.ch>)
Список 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@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: "Dave Page"
Дата:
Сообщение: Re: GUI Interface
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: GUI Interface