Bug in pg_dump

The example from Tom Lane below results in a database which is not
possible to correctly dump using pg_dump.

The view v1 strangely becomes a table in the dump output?!

It's probably a quite useless database to dump in the first place, but
that is no excuse to generate an invalid dump, it would be better to
throw an exception and complain about "your database is retarded,
refusing to dump" or something like that.

regression=# \d
List of relations
Schema | Name | Type | Owner
--------+------+-------+----------
public | tt | table | postgres
public | v1 | view | postgres
public | v2 | view | postgres
(3 rows)

ubuntu(at)ubuntu:/crypt/postgresql-9.1alpha3/src/bin/pg_dump$ ./pg_dump
regression | grep -v -E '^--' | grep -E '^.+$' | grep -v SET
CREATE OR REPLACE PROCEDURAL LANGUAGE plpgsql;
ALTER PROCEDURAL LANGUAGE plpgsql OWNER TO ubuntu;
CREATE TABLE tt (
f1 integer,
f2 integer
);
ALTER TABLE public.tt OWNER TO postgres;
CREATE TABLE v1 (
f1 integer,
f2 integer
);
ALTER TABLE public.v1 OWNER TO postgres;
CREATE VIEW v2 AS
SELECT v1.f1, v1.f2 FROM v1;
ALTER TABLE public.v2 OWNER TO postgres;
COPY tt (f1, f2) FROM stdin;
\.
CREATE RULE "_RETURN" AS ON SELECT TO v1 DO INSTEAD SELECT v2.f1, v2.f2 FROM v2;
REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM ubuntu;
GRANT ALL ON SCHEMA public TO ubuntu;
GRANT ALL ON SCHEMA public TO PUBLIC;

2011/1/12 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> regression=# create table tt(f1 int, f2 int);
> CREATE TABLE
> regression=# create view v1 as select * from tt;
> CREATE VIEW
> regression=# create view v2 as select * from v1;
> CREATE VIEW
> regression=# create or replace view v1 as select * from v2;
> CREATE VIEW
> regression=# drop view v1;
> ERROR:  cannot drop view v1 because other objects depend on it
> DETAIL:  view v2 depends on view v1
> HINT:  Use DROP ... CASCADE to drop the dependent objects too.
> regression=# drop view v2;
> ERROR:  cannot drop view v2 because other objects depend on it
> DETAIL:  view v1 depends on view v2
> HINT:  Use DROP ... CASCADE to drop the dependent objects too.
>
> This isn't particularly *useful*, maybe, but it's hardly "impossible".
> And if we analyzed function dependencies in any detail, circular
> dependencies among functions would be possible (and useful).
>
>                        regards, tom lane

--
Best regards,

Joel Jacobson
Glue Finance