Re: creating objects in pg_catalog

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: creating objects in pg_catalog
Date: 2012-06-06 20:39:42
Message-ID: 14072.1339015182@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Right now, you can't directly create a relation (table, index,
> composite type) in the pg_catalog schema, but you can create a
> non-relation (function, domain, etc.) in the pg_catalog schema.

Surely this is true only for superusers. Superusers can do whatever
they want anyway, no?

> Tabula raza, I'd argue for getting tough on this, and error out on any
> attempt to get a user-created SQL object into pg_catalog by any means,
> unless allow_system_table_mods is set.

allow_system_table_mods is mainly intended to prevent people from
altering the schemas of system catalogs, since it's more than likely
that the backend C code will fail (nastily) to cope with such changes.
I don't think it follows that we should prevent superusers from doing
things that are perfectly safe, like adding new functions in pg_catalog.

It's very likely that the specific restrictions enforced by
allow_system_table_mods could stand a fresh look, but I don't agree
with the idea of radically changing its charter. Nor do I think we
need to put training wheels on superusers for any changes that aren't
demonstrably likely to result in unrecoverable database corruption.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Koposov 2012-06-06 20:42:45 Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Previous Message Robert Haas 2012-06-06 20:27:50 Re: Avoiding adjacent checkpoint records