Denis Laxalde a écrit :
Michael Paquier a écrit :
On Wed, Sep 07, 2022 at 12:50:32PM +0500, Ibrar Ahmed wrote:
The patch requires a rebase, please do that.
Hunk #5 succeeded at 454 (offset 28 lines). 1 out of 5 hunks FAILED
-- saving rejects to file doc/src/sgml/ref/grant.sgml.rej
There has
On Wed, Sep 07, 2022 at 12:50:32PM +0500, Ibrar Ahmed wrote:
> The patch requires a rebase, please do that.
>
> Hunk #5 succeeded at 454 (offset 28 lines). 1 out of 5 hunks FAILED
> -- saving rejects to file doc/src/sgml/ref/grant.sgml.rej
There has been no updates on this thread for one month, s
On Mon, Jul 25, 2022 at 4:03 AM Kenaniah Cerny wrote:
> Hi Antonin,
>
> Thank you again for the detailed review and questions. It was encouraging
> to see the increasing level of nuance in this latest round.
>
> It's not clear from the explanation of the GRANT ... IN DATABASE ... /
>> GRANT
>>
Hi Antonin,
Thank you again for the detailed review and questions. It was encouraging
to see the increasing level of nuance in this latest round.
It's not clear from the explanation of the GRANT ... IN DATABASE ... / GRANT
> ... IN CURRENT DATABASE ... that, even if "membership in ... will be
>
Kenaniah Cerny wrote:
> Rebased yet again...
>
> On Mon, Jul 4, 2022 at 1:17 PM Kenaniah Cerny wrote:
> The "unsafe_tests" directory is where the pre-existing role tests were
> located. According to the readme of the "unsafe_tests" directory, the tests
> contained within are not run during
Rebased yet again...
On Mon, Jul 4, 2022 at 1:17 PM Kenaniah Cerny wrote:
> Hi Antonin,
>
> First of all, thank you so much for taking the time to review my patch.
> I'll answer your questions in reverse order:
>
> The "unsafe_tests" directory is where the pre-existing role tests were
> located.
Hi Antonin,
First of all, thank you so much for taking the time to review my patch.
I'll answer your questions in reverse order:
The "unsafe_tests" directory is where the pre-existing role tests were
located. According to the readme of the "unsafe_tests" directory, the tests
contained within are
Kenaniah Cerny wrote:
> Attached is a newly-rebased patch -- would love to get a review from someone
> whenever possible.
I've picked this patch for a review. The patch currently does not apply to the
master branch, so I could only read the diff. Following are my comments:
* I think that roles
Patch doesn't apply again...
[image: 1jfj7m.jpg]
Hi all,
cfbot is once again green as of the v7 patch:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/37/3374
- Kenaniah
Thanks Andres,
An updated patch is attached.
- Kenaniah
On Mon, Mar 21, 2022 at 5:40 PM Andres Freund wrote:
> Hi,
>
> On 2022-01-22 22:56:44 +0800, Julien Rouhaud wrote:
> > On Sat, Jan 22, 2022 at 05:28:05AM -0800, Kenaniah Cerny wrote:
> > > Thank you so much for the backtrace!
> > >
> > >
Hi,
On 2022-01-22 22:56:44 +0800, Julien Rouhaud wrote:
> On Sat, Jan 22, 2022 at 05:28:05AM -0800, Kenaniah Cerny wrote:
> > Thank you so much for the backtrace!
> >
> > This latest patch should address by moving the dumpRoleMembership call to
> > before the pointer is closed.
>
> Thanks! The
Hi,
On Sat, Jan 22, 2022 at 05:28:05AM -0800, Kenaniah Cerny wrote:
> Thank you so much for the backtrace!
>
> This latest patch should address by moving the dumpRoleMembership call to
> before the pointer is closed.
Thanks! The cfbot turned green since:
https://cirrus-ci.com/github/postgresql-
Thank you so much for the backtrace!
This latest patch should address by moving the dumpRoleMembership call to
before the pointer is closed.
On Sat, Jan 22, 2022 at 1:11 AM Julien Rouhaud wrote:
> Hi,
>
> On Fri, Jan 21, 2022 at 07:01:21PM -0800, Kenaniah Cerny wrote:
> > Thanks for the feedbac
Hi,
On Fri, Jan 21, 2022 at 07:01:21PM -0800, Kenaniah Cerny wrote:
> Thanks for the feedback.
>
> I have attached an alternate version of the v5 patch that incorporates the
> suggested changes to the documentation and DRYs up some of the acl.c code
> for comparison. As for the databaseOid / Inva
Thanks for the feedback.
I have attached an alternate version of the v5 patch that incorporates the
suggested changes to the documentation and DRYs up some of the acl.c code
for comparison. As for the databaseOid / InvalidOid parameter, I'm open to
any suggestions for how to make that even cleaner
On Fri, Jan 21, 2022 at 3:12 PM Kenaniah Cerny wrote:
> The latest rebased version of the patch is attached.
>
As I was just reminded, we tend to avoid specifying specific PostgreSQL
versions in our documentation. We just say what the current version does.
Here, the note sentences at lines 62 a
The latest rebased version of the patch is attached.
On Tue, Jan 11, 2022 at 11:01 PM Julien Rouhaud wrote:
> Hi,
>
> On Thu, Dec 2, 2021 at 2:26 AM Kenaniah Cerny wrote:
> >
> > Attached is a rebased version of the patch that omits catversion.h in
> order to avoid conflicts.
>
> Unfortunately
Hi,
On Thu, Dec 2, 2021 at 2:26 AM Kenaniah Cerny wrote:
>
> Attached is a rebased version of the patch that omits catversion.h in order
> to avoid conflicts.
Unfortunately even without that the patch doesn't apply anymore
according to the cfbot: http://cfbot.cputube.org/patch_36_3374.log
1 ou
Thank you for the advice!
Attached is a rebased version of the patch that omits catversion.h in order
to avoid conflicts.
On Wed, Nov 17, 2021 at 6:17 AM Daniel Gustafsson wrote:
> > On 28 Oct 2021, at 21:39, Kenaniah Cerny wrote:
>
> > Thank you Asif. A rebased patch is attached.
>
> This pat
> On 28 Oct 2021, at 21:39, Kenaniah Cerny wrote:
> Thank you Asif. A rebased patch is attached.
This patch fails to apply yet again, this time due to a collusion in
catversion.h. I think it's fine to omit the change in catversion.h as it's
likely to repeatedly cause conflicts, and instead just
Thank you Asif. A rebased patch is attached.
On Thu, Oct 28, 2021 at 11:04 AM Asif Rehman wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: not tested
> Docum
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
The patch does not apply on HEAD anymore. Looks like it needs to be rebased.
Hi all,
Thank you for the feedback so far!
Attached is a completed implementation (including tests and documentation).
Based on the feedback I have received so far, I will be submitting this
implementation to the commitfest.
Thanks again,
Kenaniah
On Mon, Oct 11, 2021 at 9:05 AM Stephen Frost
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Monday, October 11, 2021, Stephen Frost wrote:
> > I don't think "just don't grant access to those other databases"
> > is actually a proper answer- there is certainly a use-case for "I want
> > user X to have read access to
On Monday, October 11, 2021, Stephen Frost wrote:
>
> I don't think "just don't grant access to those other databases"
> is actually a proper answer- there is certainly a use-case for "I want
> user X to have read access to all tables in *this* database, and also
> allow them to connect to some o
On Mon, 11 Oct 2021 at 11:01, Stephen Frost wrote:
> Having an ability to GRANT predefined roles within a particular database
> is certainly something that I'd considered when adding the pg_read/write
> data roles. I'm not super thrilled with the idea of adding a column to
> pg_auth_members jus
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Sun, Oct 10, 2021 at 2:29 PM Kenaniah Cerny wrote:
>
> > In building off of prior art regarding the 'pg_read_all_data' and
> > 'pg_write_all_data' roles, I would like to propose an extension to roles
> > that would allow for
On Sun, Oct 10, 2021 at 2:29 PM Kenaniah Cerny wrote:
> In building off of prior art regarding the 'pg_read_all_data' and
> 'pg_write_all_data' roles, I would like to propose an extension to roles
> that would allow for database-specific role memberships (for the purpose of
> granting database-sp
Hi all,
In building off of prior art regarding the 'pg_read_all_data' and
'pg_write_all_data' roles, I would like to propose an extension to roles
that would allow for database-specific role memberships (for the purpose of
granting database-specific privileges) as an additional layer of
abstractio
30 matches
Mail list logo
