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, whic
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 Ja
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 mention
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 Mon
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 06:14:4
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 regress_arg
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
0001-m
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 so
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
> >
> > Ah
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:
> > ./src/test/modules/test_pg_
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
> +NO_INSTALLCHEC
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 insta
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 seein
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
6928
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 regr
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 test_rls_
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 have
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
> > tha
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 attent
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 — https://www.E
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 o
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 confu
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 an
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. I
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 to
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 prefi
.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 it
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 han
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 e
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, then
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 rol
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 t
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 woul
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 restrictiv
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 defin
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 paramet
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. I
48 matches
Mail list logo
