Re: User-Id Tracking when Portal was started
От | Kohei KaiGai |
---|---|
Тема | Re: User-Id Tracking when Portal was started |
Дата | |
Msg-id | CADyhKSUUtCFc27extrqejvYZKPAHP_ovvipU7vG9NOfTeksG2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: User-Id Tracking when Portal was started (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: User-Id Tracking when Portal was started
|
Список | pgsql-hackers |
2012/7/4 Robert Haas <robertmhaas@gmail.com>: > On Tue, Jul 3, 2012 at 12:46 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >>> My point is that it seems like a bug that the secContext gets restored >>> in one case and not the other, depending on which user ID was specified >>> in SET SESSION AUTHORIZATION. >>> >> Sorry, the above description mention about a case when it does not use >> the marker to distinguish a case to switch user-id from a case not to switch. >> (I though I was asked the behavior if this logic always switches / >> restores ids.) >> >> The patch itself works correctly, no regression test failed even though >> several tests switches user-id using SET SESSION AUTHORIZATION. > > I don't believe that proves anything. There are lots of things that > aren't tested by the regression tests, and there's no guarantee that > any you've added cover all bases, either. We always treat user-ID and > security context as a unit; you haven't given any reason why this case > should be handled differently, and I bet it shouldn't. > This patch always handles user-id and security context as a unit. In case when it was switched, then it shall be always restored. And, in case when it was not switched, then it shall never be restored. Was my explanation confusing? -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: