Re: User-Id Tracking when Portal was started

On Wed, Jul 4, 2012 at 4:24 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> 2012/7/4 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Tue, Jul 3, 2012 at 12:46 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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?

It's not that your explanation is confusing; it's that it doesn't
match the code.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company