| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "Marti R(dot)" <marti(at)juffo(dot)org>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: alter user/role CURRENT_USER |
| Date: | 2014-10-30 20:59:45 |
| Message-ID: | 9875.1414702785@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> The other idea which comes to mind is- could we try to actually resolve
> what the 'right' answer is here, instead of setting a special value and
> then having to detect and fix it later?
No, absolutely not. Read the NOTES at the head of gram.y. Or if you
need it spelled out: when we run the bison parser, we may not be inside a
transaction at all, and even if we are, we aren't necessarily going to
be seeing the same current user that will apply when the parsetree is
ultimately executed. (Consider a query inside a plpgsql function, which
might be called under multiple userids over the course of a session.)
I think Alvaro's suggestion is a perfectly appropriate solution.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-10-30 21:11:36 | Re: alter user/role CURRENT_USER |
| Previous Message | Tom Lane | 2014-10-30 19:52:01 | Re: infinite loop in _bt_getstackbuf |