On 2014-03-12 20:54:36 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 12, 2014 at 9:19 AM, Andres Freund and...@2ndquadrant.com
wrote:
Except that we don't have the infrastructure to perform such checks
(neither partial, nor expression indexes, no exclusion
On Mar 12, 2014 1:46 AM, Josh Berkus j...@agliodbs.com wrote:
On 03/11/2014 06:57 AM, Tom Lane wrote:
Mind you, I wouldn't be unhappy to see it go away; it's a kluge and
always
has been. I'm just expecting lots of push-back if we try. And it's
kind
of hard to resist push-back when you
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't have
ambiguity in GRANT and similar commands. This
On 2014-03-12 10:03:42 -0300, Alvaro Herrera wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't
Jaime Casanova ja...@2ndquadrant.com writes:
On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But not sure how to define a unique
index that allows (joe, db1) to coexist with (joe, db2) but not with
(joe, 0).
and why you want that restriction?
So that if I say GRANT
Magnus Hagander mag...@hagander.net writes:
Yeah, what we really need is encapsulated per-DB users and local
superusers. I think every agrees that this is the goal, but nobody
wants to put in the work to implement a generalized solution.
Encapsulated would probably be the doable part. But
On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Yeah, what we really need is encapsulated per-DB users and local
superusers. I think every agrees that this is the goal, but nobody
wants to put in the work to implement a
* Magnus Hagander (mag...@hagander.net) wrote:
On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I share your doubts as to how useful such a concept actually is, but
it'd work if we had real local users.
It can also do interesting things like ALTER SYSTEM, replication,
Magnus Hagander mag...@hagander.net writes:
On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
A local user with the superuser privilege would not be able to log into
another database, because superuser doesn't give you any extra privilege
until you've logged in.
Yeah, as
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Magnus Hagander mag...@hagander.net writes:
You could COPY over the hba file or sometihng like that :) Or just
pg_read_binary_file() on the files in another database, which is accessible
through SQL as well.
More directly, he could alter pg_authid
On 03/12/2014 12:22 AM, Magnus Hagander wrote:
On Mar 12, 2014 1:46 AM, Josh Berkus j...@agliodbs.com wrote:
Yeah, what we really need is encapsulated per-DB users and local
superusers. I think every agrees that this is the goal, but nobody
wants to put in the work to implement a generalized
On 03/12/2014 02:09 PM, Josh Berkus wrote:
On 03/12/2014 12:22 AM, Magnus Hagander wrote:
On Mar 12, 2014 1:46 AM, Josh Berkus j...@agliodbs.com wrote:
Yeah, what we really need is encapsulated per-DB users and local
superusers. I think every agrees that this is the goal, but nobody
wants to
* Josh Berkus (j...@agliodbs.com) wrote:
Local superusers (maybe this concept needs another name) would be able
to do the following things in a *single* database:
1 change permissions for other users on that database and its objects
What about bypass permissions, ala what superuser does
On 03/12/2014 11:25 AM, Stephen Frost wrote:
* Josh Berkus (j...@agliodbs.com) wrote:
Local superusers (maybe this concept needs another name) would be able
to do the following things in a *single* database:
1 change permissions for other users on that database and its objects
What about
Andrew Dunstan and...@dunslane.net writes:
On 03/12/2014 02:09 PM, Josh Berkus wrote:
Well, if you really want my I want a pony list:
Local superusers (maybe this concept needs another name) would be able
to do the following things in a *single* database:
1 change permissions for other
On 03/12/2014 11:40 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 03/12/2014 02:09 PM, Josh Berkus wrote:
Well, if you really want my I want a pony list:
Local superusers (maybe this concept needs another name) would be able
to do the following things in a *single*
* Josh Berkus (j...@agliodbs.com) wrote:
On 03/12/2014 11:25 AM, Stephen Frost wrote:
* Josh Berkus (j...@agliodbs.com) wrote:
Local superusers (maybe this concept needs another name) would be able
to do the following things in a *single* database:
1 change permissions for other users
On Wed, Mar 12, 2014 at 9:19 AM, Andres Freund and...@2ndquadrant.com wrote:
Isn't this just a case of creating a suitable operator and an exclusion
constraint? Defining the constraint in BKI might require extra
infrastructure, but it should be possible.
Except that we don't have the
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 12, 2014 at 9:19 AM, Andres Freund and...@2ndquadrant.com wrote:
Except that we don't have the infrastructure to perform such checks
(neither partial, nor expression indexes, no exclusion constraints) on
system tables atm. So it's not a
On Sun, Mar 9, 2014 at 9:00 PM, Thom Brown t...@linux.com wrote:
Hi,
I've noticed that db_user_namespace has had the following note
attached to it since 2002:
This feature is intended as a temporary measure until a complete
solution is found. At that time, this option will be removed.
It
Magnus Hagander mag...@hagander.net writes:
On Sun, Mar 9, 2014 at 9:00 PM, Thom Brown t...@linux.com wrote:
It will be 12 years this year since this temporary measure was
added. I'm just wondering, is there any complete solution that
anyone had in mind yet? Or should this just be
On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Sun, Mar 9, 2014 at 9:00 PM, Thom Brown t...@linux.com wrote:
It will be 12 years this year since this temporary measure was
added. I'm just wondering, is there any complete
Magnus Hagander mag...@hagander.net writes:
On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Are you claiming there are no users, and if so, on what evidence?
I am claiming that I don't think anybody is using that, yes.
Based on the fact that I have *never* come across it
On 03/11/2014 09:57 AM, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Are you claiming there are no users, and if so, on what evidence?
I am claiming that I don't think anybody is using that, yes.
Based on the
* Andrew Dunstan (and...@dunslane.net) wrote:
Or we try to make it work. I don't think the idea is inherently bad,
and I know there are people (like ISPs) who would like to have it
work properly. Maybe in these days when most people are on dedicated
VMs this matters less, but I don't think
On 03/11/2014 12:37 PM, Stephen Frost wrote:
Isn't the other issue for ISPs essentially that we don't have row-level
security for our global catalogs? as in- we can't limit what's in
pg_authid to only those entries a given user should be able to see? I
don't think db_user_namespace addresses
Josh Berkus j...@agliodbs.com writes:
On 03/11/2014 06:57 AM, Tom Lane wrote:
Mind you, I wouldn't be unhappy to see it go away; it's a kluge and always
has been. I'm just expecting lots of push-back if we try. And it's kind
of hard to resist push-back when you don't have a substitute to
Andrew Dunstan and...@dunslane.net writes:
The docs say:
db_user_namespace causes the client's and server's user name
representation to differ. Authentication checks are always done with
the server's user name so authentication methods must be configured
for the server's user
On 03/11/2014 07:41 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The docs say:
db_user_namespace causes the client's and server's user name
representation to differ. Authentication checks are always done with
the server's user name so authentication methods
On 03/11/2014 06:57 AM, Tom Lane wrote:
Mind you, I wouldn't be unhappy to see it go away; it's a kluge and always
has been. I'm just expecting lots of push-back if we try. And it's kind
of hard to resist push-back when you don't have a substitute to offer.
Yeah, what we really need is
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't have
ambiguity in GRANT and similar commands. This doesn't seem simple to
enforce (if we supported partial indexes on
Andrew Dunstan and...@dunslane.net writes:
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't have
ambiguity in GRANT and similar commands. This doesn't seem simple to
So I'll admit to using it, only in toy setups...
I use it with trust and ident, on local connections though, not password
I try to keep my laptops clean of mysqld, and I use PG. And only on my
laptop/PC, I make a database for every user... And every app get's a
userid, and a schema
On 03/11/2014 11:06 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't have
ambiguity in GRANT and similar
On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But not sure how to define a unique
index that allows (joe, db1) to coexist with (joe, db2) but not with
(joe, 0).
and why you want that restriction? when you login you need to specify
the db, right? if you don't specify the
On 03/11/2014 11:50 PM, Jaime Casanova wrote:
On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But not sure how to define a unique
index that allows (joe, db1) to coexist with (joe, db2) but not with
(joe, 0).
and why you want that restriction? when you login you need to
On Tue, Mar 11, 2014 at 10:52 PM, Andrew Dunstan and...@dunslane.net wrote:
On 03/11/2014 11:50 PM, Jaime Casanova wrote:
On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But not sure how to define a unique
index that allows (joe, db1) to coexist with (joe, db2) but not
Andrew Dunstan wrote
On 03/11/2014 11:50 PM, Jaime Casanova wrote:
On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane lt;
tgl@.pa
gt; wrote:
But not sure how to define a unique
index that allows (joe, db1) to coexist with (joe, db2) but not with
(joe, 0).
and why you want that restriction? when
38 matches
Mail list logo
