Re: User-Id Tracking when Portal was started
| От | Kohei KaiGai |
|---|---|
| Тема | Re: User-Id Tracking when Portal was started |
| Дата | |
| Msg-id | CADyhKSX6U5UbGznkXe5iNaWG+ADAsuqdUbAkbhLTd+QXH=2_9g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: User-Id Tracking when Portal was started (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: User-Id Tracking when Portal was started
|
| Список | pgsql-hackers |
2012/7/3 Tom Lane <tgl@sss.pgh.pa.us>: > Kohei KaiGai <kaigai@kaigai.gr.jp> writes: >> 2012/7/3 Robert Haas <robertmhaas@gmail.com>: >>> Why not just save and restore the user ID and security context >>> unconditionally, instead of doing this kind of dance? >>> >>> + if (portal->userId != GetUserId()) >>> + SetUserIdAndSecContext(portal->userId, portal->secCo >>> + else >>> + saveUserId = InvalidOid; >>> >> In case when CurrentUserId was updated during the code block >> (E.g, execution of SET SESSION AUTHORIZATION), it overwrites >> this update on restoring user-id and security-context. > > Um... what should happen if there was a SET SESSION AUTHORIZATION > to the portal's userId? This test will think nothing happened. > In my test, all the jobs by SET SESSION AUTHORIZATION was cleaned-up... It makes nothing happen from viewpoint of users. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: