Christopher Kings-Lynne <chriskl@familyhealth.com.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
