Re: [HACKERS] create rule changes table to view ? - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] create rule changes table to view ?
Date
Msg-id m113ifM-0003kMC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] create rule changes table to view ?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:

>
> Ryan Bradetich <rbrad@hpb50023.boi.hp.com> writes:
> > psql declares the the type to be view? if the relkind is a relation
> > and the relhasrules = true in pg_class for that entry.  I will pull
> > the latest source and see if I can come up with a better way for
> > determining the type tomorrow, if someone else doesn't beat me to it
>
> The way Jan explained it to me, a view *is* a table that happens to
> have an "on select do instead" rule attached to it.  If the table
> has data in it (which it normally wouldn't) you can't see that data
> anyway because of the select rule.

    Right

>
> This is another example like SERIAL columns, UNIQUE columns, etc, where
> we are not really leaving enough information in the system tables to
> allow accurate reconstruction of what the user originally said.  Was
> it a CREATE VIEW, or a CREATE TABLE and manual attachment of a rule?
> No way to tell.  In one sense it doesn't matter a whole lot, but for
> psql displays and pg_dump it would be nice to know what happened.

    Oh - but for VIEW's we leave enough information in the system
    tables.  Rules on event SELECT actually

    1.  must be INSTEAD

    2.  have exactly one action.  This  action  must  be  another
        SELECT  which  exactly  produces  a  targetlist where all
        attributes are in the order  and  of  the  types  of  the
        tables schema

    3.  must be named "_RET<tablename>"

    4.  must be the only rule on event SELECT.

    These  restrictions  clearly  tell  that if a table has an ON
    SELECT rule, it IS A  VIEW!  There  is  absolutely  no  other
    possibility.

    Stonebraker  originally  planned  to  have other rules on the
    SELECT case too, namely attribute rules which only rewrite  a
    single  attribute  of  a  table,  and  rules performing other
    actions than a SELECT if someone scans that table. But  AFAIK
    these plans never materialized.

    The  problem  on  SELECT  rules  is  that  they  have totally
    different semantics than any other rules in  that  they  must
    get  applied  not  only  on  SELECT.  Instead we also rewrite
    things like

        INSERT ... SELECT

    and

        DELETE ... WHERE x = view.y AND view.z = ...

    so views become usable in all kinds of statements.

    When fixing the rewrite system for v6.4 I decided to simplify
    the  rewriting of SELECT rules by restricting them totally to
    views.  After that, I simply took out  all  that  screwed  up
    code dealing with attribute rewriting and sent it down to the
    bit recycling.

    I don't plan to turn this wheel back.  And  if  someone  else
    ever succeeds in doing so, we'll have another "ruleguru" :-)

    So  if  you  find  an  entry in pg_rewrite with ev_type=1 and
    ev_class=<my_tables_oid>, then my_table is a view  -  end  of
    story.


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

pgsql-hackers by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] Updated TODO list
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] create rule changes table to view ?