Hi,
I'm currently thinking about multiple action and non-INSTEAD
rules ON SELECT. I'm not sure what users might expect when
they get fired.
Well if a user types SELECT ... FROM tab and there are rules
ON SELECT TO tab, then of course. But what about if the user
issues an INSERT INTO x SELECT ... FROM tab or an UPDATE x
SET col = tab.attr? In fact tab is scanned and returns data.
Should the rule ON SELECT then be fired too?
And what the hell is all that good for? Do we need other
rules ON SELECT than those that build views (which we have
now)? Tracing which data one user uses? Cannot be what rules
are made for.
If nobody votes against, I would only add some code checking
that there is at max one INSTEAD SELECT rule that returns
exactly the relations tuple structure ON SELECT (currently
with CREATE TABLE, CREATE RULE someone can setup a situation
that crashes the backend on SELECT). So SELECT rules are
totally restricted to view building and nothing else.
After that I'll tidy up the rewrite code (the work I've done
screwed it up a little with nearly duplicate functions).
Anything except for bug fixing is then delayed for 6.5.
I still have in mind that we wanted to have views of UNIONS,
DISTINCT views and some more. But since they require totally
different semantics (the resulting plan must have something
like a subselect of union in the case of an UPDATE...) this
is far too much and has bad bad traps deep inside. We all
don't want to fall into one during BETA.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
