Re: Feature suggestions (long)

On Mon, May 19, 2003 at 03:58:24PM +0200, Zeugswetter Andreas SB SD wrote:
> The update needs one for the case where the tuple stays in the same
> partial table, and the second for moving it to another table. The first is
> simple (where old.x = new.x), the second must delete the original and
> insert a new row into the view. The view insert rule handles the
> distribution (might be, that there are TODO's here, my data stays in
> place). The additional problem with the second rule is, that the returned
> UPDATE tag (iirc) does not return the correct number of rows (deleted +
> inserted rows, see lengthy thread about the return tag). Whether that is
> an actual problem will depend on your apps.

Hmm, it's easy when you put it like that. Still, each update will be
converted into a whole host of inserts and deletes, so your N squared
complexity is still there. One thing is that the rules are always expanded,
whether or not any rows match. You'll get lots and lots of little queries.
One of my other wishes was for the EXPLAIN output to remain somewhat
legible.

Also, such a setup could never take advantage of the multi-table indexes I
suggested, since the whole benefit of those comes from treating a whole
inheritence hierarchy as a single virtual table (the UNIQUEness checks are
just a really cool bonus).

Anyway, the general trend seems to be against the idea so I may as well go
think of something else :)
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> "the West won the world not by the superiority of its ideas or values or
> religion but rather by its superiority in applying organized violence.
> Westerners often forget this fact, non-Westerners never do."
>   - Samuel P. Huntington