Re: Backend-internal SPI operations

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