rules ON SELECT

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) #