Re: db_user_namespace a "temporary measure" - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: db_user_namespace a "temporary measure"
Date
Msg-id CABUevEzSx1=_bPEpuhg4-7rwPeVDNwX6YJA3VGXfMKm_hASBwg@mail.gmail.com
Whole thread Raw
In response to Re: db_user_namespace a "temporary measure"  (Josh Berkus <josh@agliodbs.com>)
Responses Re: db_user_namespace a "temporary measure"  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
<p dir="ltr"><br /> On Mar 12, 2014 1:46 AM, "Josh Berkus" <<a
href="mailto:josh@agliodbs.com">josh@agliodbs.com</a>>wrote:<br /> ><br /> > On 03/11/2014 06:57 AM, Tom Lane
wrote:<br/> > > Mind you, I wouldn't be unhappy to see it go away; it's a kluge and always<br /> > > has
been. I'm just expecting lots of push-back if we try.  And it's kind<br /> > > of hard to resist push-back when
youdon't have a substitute to offer.<br /> ><br /> > Yeah, what we really need is encapsulated per-DB users and
local<br/> > superusers.  I think every agrees that this is the goal, but nobody<br /> > wants to put in the work
toimplement a generalized solution.<br /> ><p dir="ltr">Encapsulated would probably be the doable part. But local
superuser?Given that a superuser can load and run binaries, how would you propose you restrict that superuser from
doinganything they want? And if you don't need that functionality, then hows it really different from being the
databaseowner? <p dir="ltr">/Magnus  

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Patch: show relation and tuple infos of a lock to acquire
Next
From: Albe Laurenz
Date:
Subject: Re: The case against multixact GUCs