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. The new pg_dump dumps in oid order in an attempt to
resolve 95% of the dependency problems, but it could never solve
a circular dependency. I was thinking that with:
(a) The creation of an ALTER FUNCTION name(args) SET ...
and
(b) Allow for functions to be created like:
CREATE FUNCTION foo(int) RETURNS int AS NULL;
which would return NULL as a result.
A complex schema with views based upon functions, tables, and
other views, and functions based upon views could be properly
dumped by dumping:
1. Function Prototypes (CREATE FUNCTION ... AS NULL)2. Types3. Aggregates4. Operators5. Sequences6. Tables
...DATA...
7. Triggers8. Function Implementations (ALTER FUNCTION ... SET)9. Rules (including Views)
10. Indexes
11. Comments :-)
Wouldn't this be a "correct" dump?
Mike Mascari