Re: db_user_namespace a "temporary measure"

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: db_user_namespace a "temporary measure"
Дата
Msg-id CABUevEzSx1=_bPEpuhg4-7rwPeVDNwX6YJA3VGXfMKm_hASBwg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: db_user_namespace a "temporary measure"  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: db_user_namespace a "temporary measure"  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Patch: show relation and tuple infos of a lock to acquire
Следующее
От: Albe Laurenz
Дата:
Сообщение: Re: The case against multixact GUCs