Re: Backend-internal SPI operations

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. 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. Types
3. Aggregates
4. Operators
5. Sequences
6. Tables

...DATA...

7. Triggers
8. Function Implementations (ALTER FUNCTION ... SET)
9. Rules (including Views)
10. Indexes
11. Comments :-)

Wouldn't this be a "correct" dump?

Mike Mascari