nce
will be keenly felt.
In practice, therefore, democracy is going to win out. That's both
good and bad. It's good because nobody wants a CoC witch-hunt, and
it's bad because there's probably some behavior which legitimately
deserves censure and will escape it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
o move us in that direction remains
unclear to me. I can't say I'm very impressed by the way the process
has been carried out up to this point; hopefully it will work out for
the best all the same.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
privileges of X.
For contemporaneous evidence of my thinking on this subject see
https://www.postgresql.org/message-id/ca+tgmobheyynw9vrhvolvd8odspbjuu9cbk6tms6owd70hf...@mail.gmail.com
particularly the paragraph that starts with "That's it".
--
Robert Haas
EDB: http://www.enterprisedb.com
* and undo the
reciprocal grants that bob and alice made to each other? Right now I
believe we just ask "is the number of sources that alices has for this
privilege still greater than zero" which only works if there are no
cycles but maybe we can do better. We'd probably need to thin
t? Why not just avoid
creating it in the first place, like this?
I haven't checked whether this fixes the bug, but if it does, we can
avoid introducing an extra branch in BitmapHeapNext.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
no-pstate.patch
Description: Binary data
0 || error_queue_space != NULL);
for (i = 0; i < pcxt->nworkers; ++i)
{
char *start;
With that fix in place, I then hit a crash in parallel bitmap heap
scan. After applying no-pstate.patch, which I just committed and
back-patched to v10, then things look OK. I'm going to apply
that you
need to have ADMIN OPTION on the role. The rule is:
1. You must have ADMIN OPTION on the target role.
2. You must also have CREATEROLE.
3. If the target role is SUPERUSER, you must be SUPERUSER.
If I'm not wrong, pg_has_role(..., 'USAGE WITH ADMIN OPTION') will
test #1 for you, but not #2 or #3.
--
Robert Haas
EDB: http://www.enterprisedb.com
(all six spellings test the same thing).
I don't have an opinion about the details, but +1 for documenting it
somehow. I also think it's weird that we have six spellings that test
the same thing, none of which are $SUBJECT. pg_has_role seems a little
half-baked to
