Re: Call for pg_dump testing

Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> Please provide example cases.

> create view v1 as select 1;
> create view v2 as select 1 + (select * from v1);
> create or replace view v1 as select * from v2;

> It seems to me that the only way to solve that one is to dump 'view
> shells'.

Hm. As of CVS tip, what you'll get is a complaint along the lines of

$ pg_dump circle >outfile
pg_dump: [sorter] WARNING: could not resolve dependency loop among these items:
pg_dump: [sorter] TABLE v1 (ID 1111 OID 920137)
pg_dump: [sorter] RULE _RETURN (ID 1174 OID 920139)
pg_dump: [sorter] TABLE v2 (ID 1112 OID 920140)
pg_dump: [sorter] RULE _RETURN (ID 1175 OID 920142)

and a dump that orders the two views arbitrarily. We can certainly add
code to do something different, but are there any real-world cases where
this is needed? The above example seems more than slightly made-up.
The views aren't actually functional anyway (trying to use either would
result in an "infinite recursion" error). Can you show me a non-broken
situation where pg_dump needs to resort to view shells?

>> Postgres has always allowed you to shoot yourself in the foot by
>> manually diddling the system catalogs. I place this in the "if it
>> hurts, don't do it" category ...

> Is there any reason for us to still allow that? What is there left that
> requires manual twiddling?

Getting out of unpleasant situations, perhaps. I would very much resist
any attempt to forbid that --- we're a long way from being so certain of
ourselves as to say that no one should ever hack the catalogs.

> Also shouldn't we really separate out the 'can modify catalogs manually'
> privilege from the 'superuser' privilege?

See pg_shadow.usecatupd. This could stand to be better supported maybe
(like with ALTER USER support)?

regards, tom lane