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.
--
Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008