Re: [HACKERS] Planner drops unreferenced tables --- bug, no?

Tom Lane wrote:

> [...]
>
> wieck(at)debis(dot)com (Jan Wieck) writes:
> >>>> Caution here!
> >>
> >>>> After rewriting there can be many unused rangetable entries
> >>>> floating around. Especially if you SELECT from a view, the
> >>>> view's relation is still mentioned in the rangetable.
>
> The other 50% of the problem is that the rewriter is overly enthusiastic
> about clearing the inFromCl flag in order to prevent views from being
> taken as valid join targets. rewriteHandler.c has two different
> routines that will clear inFromCl flags, and they're both bogus:
>
> [...]
>
> Jan, what do you think of this? In particular, what do you think should
> happen in the following cases:
> 1. Table has an ON SELECT *not* INSTEAD rule.
> 2. There is an ON SELECT (with or without INSTEAD) rule for one or
> more fields of the table, but not for the whole table.
>
> I'm not at all clear on the semantics of those kinds of rules, so I
> don't know if they should remove the original table from the join set
> or not. (I'm also confused about ON SELECT INSTEAD where the INSTEAD
> is not a select; is that even legal?)
>
> Also, would it be a good idea to propagate a source view's inFromCl
> flag into the substituted tables? (That is, when firing a select rule
> for a table that wasn't marked inFromCl to begin with, clear the
> inFromCl flags of all RTEs that it adds to the query.) I am not sure
> if this is appropriate or not.

Don't worry about it, those rules cannot occur and I'm sure
we'll never reincarnate them in the future.

The only allowed rule ON SELECT is one that

- IS INSTEAD
- is named "_RET<relation-name>"
- has one action which must be another SELECT with a
targetlist producing exactly the relations attribute list.

Again: If a relation has a rule ON SELECT, it IS A VIEW. No
relation can have more that one rule ON SELECT.

I've disabled all the other cases in RewriteDefine() on v6.4
- I think - because of the unclear semantics. Rules ON SELECT
where planned to have different actions or rewrite single
attributes too. But ON SELECT rules must be applied on all
relations which get scanned, so if there would be a rule ON
SELECT that inserts some logging into another relation, this
would actually occur ON UPDATE and ON DELETE to it's relation
too because to do the UPDATE/DELETE it's relation has to be
scanned.

I think it's correct to MOVE the inFromCl from the relation
rewritten to the join relations coming with the view's rule.
Thus clear it on the RTE rewritten and on the first two of
the rules (which are allways NEW and OLD for all rules). Then
set all other RTE's which come from the view to the former
inFromCl state of the rewritten RTE.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #