Horton

Re: Possible regression setting GUCs on \connect

Jonathan S. Katz <jkatz@postgresql.org>

View thread View on postgr.es
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Alexander Korotkov <aekorotkov@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>, David Steele <david@pgmasters.net>, Pg Hackers <pgsql-hackers@postgresql.org>, rmt@lists.postgresql.org
Date: 2023-04-28T13:42:03Z
Lists: pgsql-hackers 
On 4/27/23 8:04 PM, Alexander Korotkov wrote:
> On Fri, Apr 28, 2023 at 2:30 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>> Additionally, I think if we start recording role OID, then we need a
>> full set of management clauses for each individual option ownership.
>> Otherwise, we would leave this new role OID without necessarily
>> management facilities.  But with them, the whole stuff will look like
>> awful overengineering.
> 
> I can also predict a lot of ambiguous cases.  For instance, we
> existing setting can be overridden with a different role OID.  If it
> has been overridden can the overwriter turn it back?

[RMT hat]

While the initial bug has been fixed, given there is discussion on 
reverting 096dd80f3, I've added this as an open item.

I want to study this a bit more before providing my own opinion on revert.

Thanks,

Jonathan

Commits

  1. Revert "Add USER SET parameter values for pg_db_role_setting"

  2. Fix wrong construct_array_builtin() call in GUCArrayDelete()

  3. In hstore_plpython, avoid crashing when return value isn't a mapping.

  4. Allow granting SET and ALTER SYSTEM privileges on GUC parameters.