Dear Greg,
I agree with the advantage.
But I'm uneasy to know what a special owner would be, pratically speaking.
Well I can't think of anywhere else in the code that would need this special
case other than creating a database.
I disagree, there are consequences. That could be
Fabien COELHO [EMAIL PROTECTED] writes:
I agree with the advantage.
But I'm uneasy to know what a special owner would be, pratically speaking.
If it would mean that everywhere in the source code where an owner is
manipulated, there must be some kind of special test for that case, I'm
not
nspacl = aclitems_switch_grantor(nspacl, datdba)
Instead of having a hard coded list of template1 objects that need to be
chowned to the database owner. Perhaps there should be a special user like
dbowner which owns the schema and whatever other objects are necessary.
[...]
I
Fabien COELHO [EMAIL PROTECTED] writes:
nspacl = aclitems_switch_grantor(nspacl, datdba)
Instead of having a hard coded list of template1 objects that need to be
chowned to the database owner. Perhaps there should be a special user like
dbowner which owns the schema and whatever other
Dear Tom,
However, I feel that the owner should own the public schema and maybe
some other stuff to be carefully selected, without bluring that important
distinction?
From a definitional standpoint I don't have a problem with that.
Good.
From an implementation standpoint, I fear it
Fabien COELHO [EMAIL PROTECTED] writes:
Another heavier but more general approach would be to add a boolean to
pg_database to tell whether the first connection housekeeping was
performed,
I was envisioning a bool column added to pg_database, and having the set
of operations just hard-coded
Dear Tom,
Another heavier but more general approach would be to add a boolean to
pg_database to tell whether the first connection housekeeping was
performed,
I was envisioning a bool column added to pg_database,
and having the set of operations just hard-coded into the backend.
Why
Fabien COELHO [EMAIL PROTECTED] writes:
I was thinking about something fuzzy enough as:
UPDATE pg_catalog.pg_namespace
SET nspowner=datdba, nspacl=NULL -- NULL means default rights...
The later is simple and makes sense anyway for a newly created database.
No, I don't think it does. The
Dear Tom,
UPDATE pg_catalog.pg_namespace
SET nspowner=datdba, nspacl=NULL -- NULL means default rights...
The later is simple and makes sense anyway for a newly created database.
No, I don't think it does. The DBA presently can set up a site-wide
policy about use of public by altering
Fabien COELHO wrote:
Dear hackers,
It seems to me that the current default setup for a new database which is
given to some user is not consistent (createdb -O calvin foo or
CREATE DATABASE foo WITH OWNER calvin).
Indeed, although the database belongs to the owner, the public schema
still
Fabien COELHO wrote:
Dear Thomas,
* create the database with the new owner specified.
-- As a superuser in the newly created database
update pg_am set amowner = {userid}
update pg_class set relowner = {userid}
You don't want to update ownership of tables in system schemas.
AFAICS, any
Thomas Swan [EMAIL PROTECTED] writes:
Fabien COELHO wrote:
You don't want to update ownership of tables in system schemas.
AFAICS, any changes they make are localized to their database not the
whole database system.
A database owner who is not a superuser should *not* be able to fool with
Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Fabien COELHO wrote:
You don't want to update ownership of tables in system schemas.
AFAICS, any changes they make are localized to their database not the
whole database system.
A database owner who is not a superuser
A database owner who is not a superuser should *not* be able to fool with
the built-in catalog entries.
Database owner != superuser, and I don't want us blurring the distinction...
Yes sure. I agree, especially if the owner is one of my students;-)
However, I feel that the owner should own
...
Without this the db owner cannot drop types that may have been copied
from the template.
Hmmm. I'm concerned about security, such as enabling the owner to load new
trusted code. You may be right, but I'm afraid it is delicate to decide
what owner fields should be changed. Owning a
Fabien COELHO [EMAIL PROTECTED] writes:
However, I feel that the owner should own the public schema and maybe
some other stuff to be carefully selected, without bluring that important
distinction?
From a definitional standpoint I don't have a problem with that. From
an implementation
Dear hackers,
It seems to me that the current default setup for a new database which is
given to some user is not consistent (createdb -O calvin foo or
CREATE DATABASE foo WITH OWNER calvin).
Indeed, although the database belongs to the owner, the public schema
still belongs to the database
17 matches
Mail list logo
