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
