Re: Backend-internal SPI operations - Mailing list pgsql-hackers

Mark Hollomon wrote:
> Mike Mascari wrote:
> >
> > Tom Lane wrote:
> > >
> > > Jan Wieck <janwieck@Yahoo.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
rulesat 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
andgot used by pg_dump.  At  that   time,  it  was  right  to  dump  views as table+rule, because   pg_dump didn't do
anythingin OID order. So views  using  sql   functions using views in turn wouldn't be dumpable otherwise.   And it was
easiertoo  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@Yahoo.com #