Peter Eisentraut <[EMAIL PROTECTED]> writes: > Right, there's a global variable that stores the database name, but that > will have to disappear. You'll have to look it up in the catalog like > everything else.
That answer is okay as long as we don't need to get at the value while outside any transaction (or in a failed transaction). Offhand I can't think of a reason we'd need to, but you'll need to look closely at the uses of that variable. [ other answers look fine ] > For those objects who don't live within schemas, you only need to own the > object or the containing table, respectively. No privilege on any schema > is required. In detail: > constraint -> owner of table > database -> owner of database > rule -> owner of table > schema -> owner of schema > trigger -> owner of table It could be argued that renaming a database should require CREATEDB rights, and that renaming a schema should require create-schema rights at the database level. For example, if user joe is given a schema joe, which he proceeds to rename to bob, it's not a lot different from him having been able to make a schema bob in the first place. ISTM if the DBA had disallowed create-schema rights to joe, he'd see this as an end run around that prohibition. The constraint/rule/trigger cases look fine, since names of those entities aren't super interesting anyway. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster