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 categ
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 re
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
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
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 username_pr
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
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_precede
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.
A
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 username_pre
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 userna
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 pg_catalog.pg_shadow_clu
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, valunt
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 G
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 use
14 matches
Mail list logo
