Horton

Re: Possible regression setting GUCs on \connect

Alexander Korotkov <aekorotkov@gmail.com>

View thread View on postgr.es
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>, David Steele <david@pgmasters.net>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2023-04-28T00:04:01Z
Lists: pgsql-hackers 
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?

------
Regards,
Alexander Korotkov

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.