Re: [HACKERS] Planner drops unreferenced tables --- bug, no? - Mailing list pgsql-hackers

Tom Lane wrote:

> [...]
>
> wieck@debis.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@debis.com (Jan Wieck) #