On Tue, Jan 3, 2023 at 5:41 PM Pavel Borisov wrote:
> On Tue, 3 Jan 2023 at 17:28, Justin Pryzby wrote:
> > I should've mentioned that the same things should be removed from
> > Makefile, too...
> >
> Thanks, Justin!
> Attached is a new patch accordingly.
Thank you. I've pushed my version,
On Tue, 3 Jan 2023 at 17:28, Justin Pryzby wrote:
>
> On Tue, Jan 03, 2023 at 02:20:38PM +0300, Pavel Borisov wrote:
> > Hi, Alexander!
> >
> > On Tue, 3 Jan 2023 at 13:48, Alexander Korotkov
> > wrote:
> > >
> > > On Tue, Jan 3, 2023 at 11:51 AM Pavel Borisov
> > > wrote:
> > > > On Tue, 3
On Tue, Jan 3, 2023 at 5:28 PM Justin Pryzby wrote:
> On Tue, Jan 03, 2023 at 09:29:00AM +0300, Alexander Korotkov wrote:
> > On Mon, Jan 2, 2023 at 6:42 PM Justin Pryzby wrote:
> > > I also suggest that meson.build should not copy regress_args.
> >
> > Good point, thanks.
>
> I should've
On Tue, Jan 03, 2023 at 02:20:38PM +0300, Pavel Borisov wrote:
> Hi, Alexander!
>
> On Tue, 3 Jan 2023 at 13:48, Alexander Korotkov wrote:
> >
> > On Tue, Jan 3, 2023 at 11:51 AM Pavel Borisov
> > wrote:
> > > On Tue, 3 Jan 2023 at 09:29, Alexander Korotkov
> > > wrote:
> > > >
> > > > On
Hi, Alexander!
On Tue, 3 Jan 2023 at 13:48, Alexander Korotkov wrote:
>
> On Tue, Jan 3, 2023 at 11:51 AM Pavel Borisov wrote:
> > On Tue, 3 Jan 2023 at 09:29, Alexander Korotkov
> > wrote:
> > >
> > > On Mon, Jan 2, 2023 at 6:42 PM Justin Pryzby wrote:
> > > > On Mon, Jan 02, 2023 at
On Tue, Jan 3, 2023 at 11:51 AM Pavel Borisov wrote:
> On Tue, 3 Jan 2023 at 09:29, Alexander Korotkov wrote:
> >
> > On Mon, Jan 2, 2023 at 6:42 PM Justin Pryzby wrote:
> > > On Mon, Jan 02, 2023 at 06:14:48PM +0300, Alexander Korotkov wrote:
> > > > I'm going to push this if no objections.
>
On Tue, 3 Jan 2023 at 09:29, Alexander Korotkov wrote:
>
> On Mon, Jan 2, 2023 at 6:42 PM Justin Pryzby wrote:
> > On Mon, Jan 02, 2023 at 06:14:48PM +0300, Alexander Korotkov wrote:
> > > I'm going to push this if no objections.
> >
> > I also suggest that meson.build should not copy
On Mon, Jan 2, 2023 at 6:42 PM Justin Pryzby wrote:
> On Mon, Jan 02, 2023 at 06:14:48PM +0300, Alexander Korotkov wrote:
> > I'm going to push this if no objections.
>
> I also suggest that meson.build should not copy regress_args.
Good point, thanks.
--
Regards,
Alexander Korotkov
On Mon, Jan 02, 2023 at 06:14:48PM +0300, Alexander Korotkov wrote:
> I'm going to push this if no objections.
I also suggest that meson.build should not copy regress_args.
--
Justin
Justin, Tom, Pavel, thank you for catching this.
On Mon, Jan 2, 2023 at 11:54 AM Pavel Borisov wrote:
> I completely agree with your analysis. Fixes by 3f0e786ccbf5 to oat
> and the other modules tests came just a couple of days before
> committing the main pg_db_role_setting commit 096dd80f3c
Hi, Justin!
On Wed, 28 Dec 2022 at 21:28, Justin Pryzby wrote:
>
> On Tue, Dec 27, 2022 at 11:29:40PM -0500, Tom Lane wrote:
> > Justin Pryzby writes:
> > > This fails when run more than once:
> > > time meson test --setup running --print
> > > test_pg_db_role_setting-running/regress
> >
> >
On Tue, Dec 27, 2022 at 11:29:40PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > This fails when run more than once:
> > time meson test --setup running --print
> > test_pg_db_role_setting-running/regress
>
> Ah.
>
> > It didn't fail for you because it says:
> >
Justin Pryzby writes:
> This fails when run more than once:
> time meson test --setup running --print
> test_pg_db_role_setting-running/regress
Ah.
> It didn't fail for you because it says:
> ./src/test/modules/test_pg_db_role_setting/Makefile
> +# disable installcheck for now
>
On Tue, Dec 27, 2022 at 01:58:14AM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > FYI: this causes meson test running ("installcheck") fail when run
> > twice. I guess that's expected to work, per:
>
> We do indeed expect that to work ... but I don't see any problem
> with repeat "make
Justin Pryzby writes:
> FYI: this causes meson test running ("installcheck") fail when run
> twice. I guess that's expected to work, per:
We do indeed expect that to work ... but I don't see any problem
with repeat "make installcheck" on HEAD. Can you provide more
detail about what you're
On Fri, Dec 09, 2022 at 01:23:56PM +0300, Alexander Korotkov wrote:
> Pushed, thanks to everyone!
FYI: this causes meson test running ("installcheck") fail when run
twice. I guess that's expected to work, per:
b62303794efd97f2afb55f1e1b82fffae2cf8a2d
f3bbe81db0e84fb486c6423a234c47091b30
On Fri, Dec 9, 2022 at 2:57 PM Pavel Borisov wrote:
> > > Pushed, thanks to everyone!
> >
> > Thank you!
> > I've found a minor thing that makes the new test fail on sifaka and
> > longfin build farm animals. If role names in regression don't start
> > with "regress_" this invokes a warning. I've
Hi, Alexander!
> Hi, Alexander!
> > Pushed, thanks to everyone!
>
> Thank you!
> I've found a minor thing that makes the new test fail on sifaka and
> longfin build farm animals. If role names in regression don't start
> with "regress_" this invokes a warning. I've consulted in other
> modules
Hi, Alexander!
> Pushed, thanks to everyone!
Thank you!
I've found a minor thing that makes the new test fail on sifaka and
longfin build farm animals. If role names in regression don't start
with "regress_" this invokes a warning. I've consulted in other
modules regression tests e.g. in
On Wed, Dec 7, 2022 at 4:36 PM Alexander Korotkov wrote:
> On Wed, Dec 7, 2022 at 1:28 AM Pavel Borisov wrote:
> > On Tue, 6 Dec 2022 at 19:01, Alexander Korotkov
> > wrote:
> > >
> > > On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov
> > > wrote:
> > > > On Mon, Dec 5, 2022 at 8:18 PM Tom
On Wed, Dec 7, 2022 at 1:28 AM Pavel Borisov wrote:
> On Tue, 6 Dec 2022 at 19:01, Alexander Korotkov wrote:
> >
> > On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov
> > wrote:
> > > On Mon, Dec 5, 2022 at 8:18 PM Tom Lane wrote:
> > > > Alvaro Herrera writes:
> > > > > I couldn't find any
Hi, Alexander!
On Tue, 6 Dec 2022 at 19:01, Alexander Korotkov wrote:
>
> On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov
> wrote:
> > On Mon, Dec 5, 2022 at 8:18 PM Tom Lane wrote:
> > > Alvaro Herrera writes:
> > > > I couldn't find any discussion of the idea of adding "(s)" to the
> >
On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov wrote:
> On Mon, Dec 5, 2022 at 8:18 PM Tom Lane wrote:
> > Alvaro Herrera writes:
> > > I couldn't find any discussion of the idea of adding "(s)" to the
> > > variable name in order to mark the variable userset in the catalog, and
> > > I
On Mon, Dec 5, 2022 at 8:18 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > I couldn't find any discussion of the idea of adding "(s)" to the
> > variable name in order to mark the variable userset in the catalog, and
> > I have to admit I find it a bit strange. Are we really agreed that
> >
Alvaro Herrera writes:
> I couldn't find any discussion of the idea of adding "(s)" to the
> variable name in order to mark the variable userset in the catalog, and
> I have to admit I find it a bit strange. Are we really agreed that
> that's the way to proceed?
I hadn't been paying close
I couldn't find any discussion of the idea of adding "(s)" to the
variable name in order to mark the variable userset in the catalog, and
I have to admit I find it a bit strange. Are we really agreed that
that's the way to proceed?
--
Álvaro Herrera PostgreSQL Developer —
Hi, Alexander!
On Mon, 5 Dec 2022 at 17:51, Alexander Korotkov wrote:
>
> On Mon, Dec 5, 2022 at 2:27 PM Pavel Borisov wrote:
> > After posting the patch I've found my own typo in docs. So corrected
> > it in v5 (PFA).
>
> The new revision of the patch is attached.
>
> I've removed the mention
On Mon, Dec 5, 2022 at 2:27 PM Pavel Borisov wrote:
> After posting the patch I've found my own typo in docs. So corrected
> it in v5 (PFA).
The new revision of the patch is attached.
I've removed the mention of "(s)" suffix from the "Server
Configuration" docs section. I think it might be
After posting the patch I've found my own typo in docs. So corrected
it in v5 (PFA).
Regards,
Pavel.
v5-0001-USER-SET-parameters-for-pg_db_role_setting.patch
Description: Binary data
> On Thu, Dec 1, 2022 at 6:14 AM Alexander Korotkov
> wrote:
> > On Wed, Nov 23, 2022 at 1:53 AM Steve Chavez wrote:
> > > So from my side this all looks good!
> >
> > Thank you for your feedback.
> >
> > The next revision of the patch is attached. It contains code
> > improvements, comments
On Thu, Dec 1, 2022 at 6:14 AM Alexander Korotkov wrote:
> On Wed, Nov 23, 2022 at 1:53 AM Steve Chavez wrote:
> > So from my side this all looks good!
>
> Thank you for your feedback.
>
> The next revision of the patch is attached. It contains code
> improvements, comments and documentation.
On Wed, Nov 23, 2022 at 1:53 AM Steve Chavez wrote:
> So from my side this all looks good!
Thank you for your feedback.
The next revision of the patch is attached. It contains code
improvements, comments and documentation. I'm going to also write
sode tests. pg_db_role_setting doesn't seem
Hey Alexander,
Looks like your latest patch addresses the original issue I posted!
So now I can create a placeholder with the USERSET modifier without a
superuser, while non-USERSET placeholders still require superuser:
```sql
create role foo noinherit;
set role to foo;
alter role foo set
.On Sun, Nov 20, 2022 at 8:48 PM Alexander Korotkov
wrote:
> I've drafted a patch implementing ALTER ROLE ... SET ... TO ... USER SET
> syntax.
>
> These options are working only for USERSET GUC variables, but require
> less privileges to set. I think there is no problem to implement
>
> Also
On Sat, Nov 19, 2022 at 4:02 AM Alexander Korotkov wrote:
> On Sat, Nov 19, 2022 at 12:41 AM Tom Lane wrote:
> > ... BTW, re-reading the commit message for a0ffa885e:
> >
> > One caveat is that PGC_USERSET GUCs are unaffected by the SET privilege
> > --- one could wish that those were
On Sat, Nov 19, 2022 at 12:41 AM Tom Lane wrote:
> ... BTW, re-reading the commit message for a0ffa885e:
>
> One caveat is that PGC_USERSET GUCs are unaffected by the SET privilege
> --- one could wish that those were handled by a revocable grant to
> PUBLIC, but they are not, because
On Sat, Nov 19, 2022 at 12:33 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > This makes sense. But do we really need to store the OID of the role?
> > validate_option_array_item() already checks if the placeholder option
> > passes validation for PGC_SUSET. So, we can just save a flag
>
... BTW, re-reading the commit message for a0ffa885e:
One caveat is that PGC_USERSET GUCs are unaffected by the SET privilege
--- one could wish that those were handled by a revocable grant to
PUBLIC, but they are not, because we couldn't make it robust enough
for GUCs defined by
Alexander Korotkov writes:
> This makes sense. But do we really need to store the OID of the role?
> validate_option_array_item() already checks if the placeholder option
> passes validation for PGC_SUSET. So, we can just save a flag
> indicating that this check was not successful. If so,
Hi!
I'd like to resume this discussion.
On Wed, Jul 20, 2022 at 6:50 PM Tom Lane wrote:
> Kyotaro Horiguchi writes:
> > At Tue, 19 Jul 2022 09:53:39 -0700, Nathan Bossart
> > wrote in
> >> Hm. I would expect ALTER ROLE to store the PGC_SUSET context when executed
> >> by a superuser or a
On Thu, Jul 21, 2022 at 10:56:41AM -0700, Nathan Bossart wrote:
> Couldn't ProcessGUCArray() use set_config_option_ext() with the context
> indicated by pg_db_role_setting? Also, instead of using PGC_USERSET in all
> the set_config_option() call sites, shouldn't we remove the "context"
> argument
On Wed, Jul 20, 2022 at 11:50:10AM -0400, Tom Lane wrote:
> I think that 13d838815 has completely changed the terms that this
> discussion needs to be conducted under. It seems clear to me now
> that if you want to relax this only-superusers restriction, what
> you have to do is store the OID of
Kyotaro Horiguchi writes:
> At Tue, 19 Jul 2022 09:53:39 -0700, Nathan Bossart
> wrote in
>> Hm. I would expect ALTER ROLE to store the PGC_SUSET context when executed
>> by a superuser or a role with privileges via pg_parameter_acl. Storing all
>> placeholder GUC settings as PGC_USERSET
At Tue, 19 Jul 2022 09:53:39 -0700, Nathan Bossart
wrote in
> On Tue, Jul 19, 2022 at 12:55:14AM -0500, Steve Chavez wrote:
> > Taking your options into consideration, for me the correct behaviour should
> > be:
> >
> > - The ALTER ROLE placeholder should always be stored with a PGC_USERSET
>
On Tue, Jul 19, 2022 at 12:55:14AM -0500, Steve Chavez wrote:
> Taking your options into consideration, for me the correct behaviour should
> be:
>
> - The ALTER ROLE placeholder should always be stored with a PGC_USERSET
> GucContext. It's a placeholder anyway, so it should be the less
Thanks a lot for the feedback Nathan.
Taking your options into consideration, for me the correct behaviour should
be:
- The ALTER ROLE placeholder should always be stored with a PGC_USERSET
GucContext. It's a placeholder anyway, so it should be the less restrictive
one. If the user wants to
On Fri, Jul 01, 2022 at 04:40:27PM -0700, Nathan Bossart wrote:
> On Sun, Jun 05, 2022 at 11:20:38PM -0500, Steve Chavez wrote:
>> However, defining placeholders at the role level require superuser:
>>
>> alter role myrole set my.username to 'tomas';
>> ERROR: permission denied to set
On Sun, Jun 05, 2022 at 11:20:38PM -0500, Steve Chavez wrote:
> However, defining placeholders at the role level require superuser:
>
> alter role myrole set my.username to 'tomas';
> ERROR: permission denied to set parameter "my.username"
>
> Which is inconsistent and surprising behavior.
ff56d10bddce1dcdabc0722a34 Mon Sep 17 00:00:00 2001
From: Steve Chavez
Date: Sun, 5 Jun 2022 19:10:52 -0500
Subject: [PATCH] Allow placeholders in ALTER ROLE w/o superuser
Removes inconsistent superuser check for placeholders on
validate_option_array_item.
---
src/backend/utils/misc/guc.c | 24 +-
49 matches
Mail list logo
