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

Reply via email to