Skip site navigation (1) Skip section navigation (2)

Re: Backend-internal SPI operations

From: Jan Wieck <janwieck(at)Yahoo(dot)com>
To: Mark Hollomon <mhh(at)nortelnetworks(dot)com>
Cc: Mike Mascari <mascarm(at)mascari(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <janwieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Backend-internal SPI operations
Date: 2000-08-30 19:01:26
Message-ID: 200008301901.OAA05725@jupiter.jw.home (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Mark Hollomon wrote:
> Mike Mascari wrote:
> >
> > Tom Lane wrote:
> > >
> > > Jan Wieck <janwieck(at)Yahoo(dot)com> writes:
> > > >     From  memory  I think views are created as CREATE TABLE, with
> > > >     an internal  DefineRuleStmt,  and  dumped  as  CREATE  TABLE,
> > > >     CREATE  RULE for sure.  So the CREATE/DROP RULE would need to
> > > >     remove/recreate the tables file (plus toast file  and  index)
> > > >     if  you want it to be consistent. Don't think you want that -
> > > >     do you?
> > >
> > > But that's only true because it's such a pain in the neck for pg_dump
> > > to discover that a table is a view.  If this could easily be told from
> > > inspection of pg_class, then it'd be no problem to dump views as
> > > CREATE VIEW statements in the first place --- obviously better, no?
> >
> > The fact that views can be created by a separate table/rule
> > sequence allows pg_dump to properly dump views which are based
> > upon functions, or views which may have dependencies on other
> > tables/views.
>
> I don't see this. a 'CREATE VIEW' cannot reference a function that
> did not exist at the time it was executed. The only way to get in
> trouble, that I see, is a DROP/CREATE RULE. But I think
> the proposal is not to allow this to happen if the rule is the
> select rule for a view.
>
> The reason that pg_dump used the table/rule sequence was that historically
> it was hard to figure out that a tuple in pg_class really represented a
> view.
>
> But I could be mistaken.

    Yep, you are.

    The   reason   why  we  dump  views  as  table+rule  is  that
    historically we wheren't able to dump views and rules at all.
    We  only  store  the parsetree representation of rules, since
    epoch. Then, someone wrote a little backend  function  that's
    able  to  backparse  these rule actions. It got enhanced by a
    couple of other smart guys and got used by pg_dump.  At  that
    time,  it  was  right  to  dump  views as table+rule, because
    pg_dump didn't do anything in OID order. So views  using  sql
    functions using views in turn wouldn't be dumpable otherwise.
    And it was easier too  because  it  was  already  done  after
    dumping  rules  at  the  end. No need to do anything else for
    views :-)

    So far about history, now the future.

    Dumping views as CREATE VIEW is cleaner. It is possible  now,
    since  we dump the objects in OID order. So I like it.  I see
    no problem with Tom's  solution,  changing  the  relkind  and
    removing  the  files  at  CREATE  RULE  time  for a couple of
    releases.  And yes, dropping the SELECT rule from a view must
    be  forbidden. As defining triggers, constraints and the like
    for them should be.


Jan

--

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



In response to

Responses

pgsql-hackers by date

Next:From: Mark HollomonDate: 2000-08-30 19:24:57
Subject: Re: Backend-internal SPI operations
Previous:From: Tom LaneDate: 2000-08-30 18:41:59
Subject: Re: Backend-internal SPI operations

pgsql-patches by date

Next:From: Mark HollomonDate: 2000-08-30 19:24:57
Subject: Re: Backend-internal SPI operations
Previous:From: Tom LaneDate: 2000-08-30 18:41:59
Subject: Re: Backend-internal SPI operations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group