On Thu, Mar 25, 2004 at 08:24:59PM -0800, Sean Chittenden wrote:
You can't think that allowing the same name to appear
globally and locally is a good idea.
Actually, I do think it is a good idea.
If I say GRANT TO foo, who am
I granting privileges to?
SET username_precedence TO
Sean Chittenden [EMAIL PROTECTED] writes:
You can't think that allowing the same name to appear
globally and locally is a good idea.
Actually, I do think it is a good idea.
If I say GRANT TO foo, who am
I granting privileges to?
SET username_precedence TO LOCAL,GLOBAL; -- I like GLOBAL
You can't think that allowing the same name to appear
globally and locally is a good idea.
Actually, I do think it is a good idea.
If I say GRANT TO foo, who am
I granting privileges to?
SET username_precedence TO LOCAL,GLOBAL; -- I like GLOBAL more than
CLUSTER
GRANT TO foo;
SET
Richard Huxton [EMAIL PROTECTED] writes:
Maybe it's me being slow, but are we not being over-complicated here? What's
wrong with saying database D1 looks up users in local table, D2 in the
global table. If you are connected to D1, then no-one can see the global
userlist.
Hmm. That would
On Friday 26 March 2004 15:09, Tom Lane wrote:
Sean Chittenden [EMAIL PROTECTED] writes:
Agreed, but if a cluster is using LOCAL USERs, I doubt highly that
CLUSTER/GLOBAL users would be in use much beyond super users. -sc
Exactly my point. I think that it might be possible for a
Sean Chittenden [EMAIL PROTECTED] writes:
Another solution would be to have CREATE USER done by a local admin
create users in the form of '[EMAIL PROTECTED]'. This prevents
duplicate usernames and allows us to use the current hack of local
database users.
Yeah, I think it would be
Another solution would be to have CREATE USER done by a local admin
create users in the form of '[EMAIL PROTECTED]'. This prevents
duplicate usernames and allows us to use the current hack of local
database users.
Yeah, I think it would be reasonable to leave that facility as-is and
invent a
I've had to work through this and have with a series of messy tables
and functions, but this screams a need for a more elegant solution.
I've dug through the archives and didn't come up with a satisfying long
term answer for virtual hosting beyond what I've already implemented.
Per cluster
On 25-Mar-04, at 8:18 PM, Sean Chittenden wrote:
I haven't read much in the last few months, but archives from 2002
suggested there wasn't much on the table in terms of making this
happen beyond adding a function that runs as a DBA to create users
(which I've done).
Well, the db_user_namespace
Sean Chittenden [EMAIL PROTECTED] writes:
What's the feasibility of augmenting the system catalogs so that
something similar to the following is possible:
CREATE VIEW pg_catalog.pg_shadow AS
SELECT usename, usesysid, usecreatedb, usesuper,
usecatupd, passwd, valuntil,
What's the feasibility of augmenting the system catalogs so that
something similar to the following is possible:
CREATE VIEW pg_catalog.pg_shadow AS
SELECT usename, usesysid, usecreatedb, usesuper,
usecatupd, passwd, valuntil, useconfig
FROM
Sean Chittenden [EMAIL PROTECTED] writes:
Come to think of it, the same risk of conflict applies for user
*names*, and we can't easily make an end-run around that.
That's why I used UNION ALL in my example. Reserved usernames that are
in the cluster should be just as valid as usernames
You can't think that allowing the same name to appear
globally and locally is a good idea.
Actually, I do think it is a good idea.
If I say GRANT TO foo, who am
I granting privileges to?
SET username_precedence TO LOCAL,GLOBAL; -- I like GLOBAL more than
CLUSTER
GRANT TO foo;
SET
I haven't read much in the last few months, but archives from 2002
suggested there wasn't much on the table in terms of making this
happen beyond adding a function that runs as a DBA to create users
(which I've done).
Well, the db_user_namespace GUC var has been implemented, but it is a
hack.
14 matches
Mail list logo
