On Fri, Feb 4, 2011 at 10:45 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>> > =A0Is there really a use case for users fiddling with pg_proc, pg_clas=
s,
>> > etc. directly?
>>
>> There's a use case for *superusers* to fiddle with them, yes.
>> (Superusers are presumed to be adults.) =A0I think I recommend a quick
>> UPDATE on some catalog at least once a month on the lists.
>>
>> You might care to consider the fact that no modern Unix system prevents
>> root from doing rm -rf /, even though that's "obviously" disastrous.
>> Yet (stretching the analogy all out of shape) there's no convenient user
>> tool for rearranging the contents of all the inodes on a filesystem.
>>
>> > At any rate, I'd be happy to drop that part of the proposal. =A0It wou=
ld
>> > be a step forward just to permit (even without
>> > allow_system_table_mods) those changes which don't alter the structure
>> > of the catalog. =A0For ALTER TABLE, the SET STATISTICS, (RE)SET
>> > (attribute_option), SET STORAGE, CLUSTER ON, SET WITHOUT CLUSTER, and
>> > (RE)SET (reloptions) forms are all things that fall into this
>> > category, I believe.
>>
>> It would be far less work to just drop allow_system_table_mods to SUSET.
>> And we wouldn't get questions about which forms of ALTER TABLE require
>> it.
>
> Are we going to make the allow_system_table_mods to SUSET change? =A0Is it
> a TODO?
I'd rather not drop it to SUSET. If we're going to make an effort in
this area, I'd rather do the work to distinguish the
destroy-your-database cases from the ones that are reasonable for an
admin to want to do.
I wouldn't make it a TODO, though. We have no consensus on what, if
anything, is worth doing.
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
