On Tue, Oct 8, 2024, at 03:48, Michael Paquier wrote:
> On Thu, Jun 13, 2024 at 07:34:30AM +0200, Joel Jacobson wrote:
>> Hmm, strange, the commitfest system didn't pick up the email with patch 0006
>> for some reason,
>> with message id 0c5a6b79-408c-4910-9b2e-4aa9a7b30...@app.fastmail.com
>>
>>
On Thu, Jun 13, 2024 at 07:34:30AM +0200, Joel Jacobson wrote:
> Hmm, strange, the commitfest system didn't pick up the email with patch 0006
> for some reason,
> with message id 0c5a6b79-408c-4910-9b2e-4aa9a7b30...@app.fastmail.com
>
> It's rebased to latest HEAD, so not sure why.
>
> Maybe it
Hmm, strange, the commitfest system didn't pick up the email with patch 0006
for some reason,
with message id 0c5a6b79-408c-4910-9b2e-4aa9a7b30...@app.fastmail.com
It's rebased to latest HEAD, so not sure why.
Maybe it got confused when I quickly afterwards sent a new email without a
patch?
He
On Thu, Jun 13, 2024, at 00:14, Joel Jacobson wrote:
> Changes since patch 0005 from 2021-03-25:
> * 0006-pg_privileges-and-pg_ownerships.patch
- Also much faster now thanks to pg_get_acl():
Test with 10 tables:
SELECT COUNT(*) FROM pg_permissions_union_all;
Time: 1466.504 ms (00:01.467)
Tim
On Thu, Mar 10, 2022, at 22:02, Chapman Flack wrote:
> It looked to me as if the -hackers messages of 25 and 26 March 2021 had
> found a consensus that a pg_get_acl() function would be a good thing,
> with the views to be implemented over that.
>
> I'm just not seeing any later patch that adds such
On 02/26/22 03:27, Joel Jacobson wrote:
> On Fri, Feb 25, 2022, at 22:12, Chapman Flack wrote:
>> I would be happy to review this patch, but a look through the email leaves me
>> thinking it may still be waiting on a C implementation of pg_get_acl(). Is
>> that
>> right?
>
> Not sure.
It looked
On Fri, Feb 25, 2022, at 22:12, Chapman Flack wrote:
> I would be happy to review this patch, but a look through the email leaves me
> thinking it may still be waiting on a C implementation of pg_get_acl(). Is
> that
> right?
Not sure.
> And perhaps a view rename to pg_privileges, following Pete
I would be happy to review this patch, but a look through the email leaves me
thinking it may still be waiting on a C implementation of pg_get_acl(). Is that
right? And perhaps a view rename to pg_privileges, following Peter's comment?
On 11.03.21 08:00, Joel Jacobson wrote:
Do we prefer "pg_permissions" or "pg_privileges"?
pg_privileges would be better. "Permissions" is not an SQL term.
On Fri, Mar 26, 2021, at 14:16, Tom Lane wrote:
> Alvaro Herrera mailto:alvherre%40alvh.no-ip.org>>
> writes:
> > On 2021-Mar-26, Joel Jacobson wrote:
> >> On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
> >> I wonder what performance will be like with lots o' objects.
>
> > I guess he is concern
Alvaro Herrera writes:
> On 2021-Mar-26, Joel Jacobson wrote:
>> On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
>> I wonder what performance will be like with lots o' objects.
> I guess he is concerned about the number of catalog accesses.
My concern is basically that you're forcing the join be
On 2021-Mar-26, Joel Jacobson wrote:
> On Fri, Mar 26, 2021, at 11:30, Alvaro Herrera wrote:
> > On 2021-Mar-26, Joel Jacobson wrote:
> >
> > > On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
> >
> > > > I wonder what performance will be like with lots o' objects.
> > >
> > > I guess pg_get_acl
On Fri, Mar 26, 2021, at 11:30, Alvaro Herrera wrote:
> On 2021-Mar-26, Joel Jacobson wrote:
>
> > On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
>
> > > I wonder what performance will be like with lots o' objects.
> >
> > I guess pg_get_acl() would need to be implemented using a switch(classid
On 2021-Mar-26, Joel Jacobson wrote:
> On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
> > I wonder what performance will be like with lots o' objects.
>
> I guess pg_get_acl() would need to be implemented using a switch(classid)
> with 36 cases (one for each class)?
No, we have a generalized
On Fri, Mar 26, 2021, at 07:53, Joel Jacobson wrote:
> On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
>> "Joel Jacobson" mailto:joel%40compiler.org>> writes:
>> > On Thu, Mar 25, 2021, at 16:16, Alvaro Herrera wrote:
>> >> Ah, of course -- the only way to obtain the acl columns is by going
>> >> t
On Thu, Mar 25, 2021, at 17:51, Tom Lane wrote:
> "Joel Jacobson" mailto:joel%40compiler.org>> writes:
> > On Thu, Mar 25, 2021, at 16:16, Alvaro Herrera wrote:
> >> Ah, of course -- the only way to obtain the acl columns is by going
> >> through the catalogs individually, so it won't be possible.
"Joel Jacobson" writes:
> On Thu, Mar 25, 2021, at 16:16, Alvaro Herrera wrote:
>> Ah, of course -- the only way to obtain the acl columns is by going
>> through the catalogs individually, so it won't be possible. I think
>> this could be fixed with some very simple, quick function pg_get_acl()
>
On Thu, Mar 25, 2021, at 16:16, Alvaro Herrera wrote:
> On 2021-Mar-25, Joel Jacobson wrote:
>
> > pg_shdepend doesn't contain the aclitem info though,
> > so it won't work for pg_permissions if we want to expose
> > privilege_type, is_grantable and grantor.
>
> Ah, of course -- the only way to o
On 2021-Mar-25, Joel Jacobson wrote:
> pg_shdepend doesn't contain the aclitem info though,
> so it won't work for pg_permissions if we want to expose
> privilege_type, is_grantable and grantor.
Ah, of course -- the only way to obtain the acl columns is by going
through the catalogs individually,
On Tue, Mar 23, 2021, at 21:39, Alvaro Herrera wrote:
>I wonder if these views should be defined on top of pg_shdepend instead
>of querying every single catalog. That would make for much shorter
>queries.
+1
pg_shdepend doesn't contain the aclitem info though,
so it won't work for pg_permissions
On 2021-Mar-08, Joel Jacobson wrote:
> $ dropuser test
> dropuser: error: removal of role "test" failed: ERROR: role "test" cannot be
> dropped because some objects depend on it
> DETAIL: 1 object in database joel
>
> Hmmm. I wonder which 1 object that could be?
BTW the easiest way to find ou
On 2021-Mar-23, Joel Jacobson wrote:
> On Thu, Mar 11, 2021, at 08:00, Joel Jacobson wrote:
> > 0004-pg_permissions-and-pg_ownerships.patch
>
> Having gotten some hands-on experience of these views for a while,
> I notice I quite often want to check the ownerships/permissions
> for some specific
On Thu, Mar 11, 2021, at 08:00, Joel Jacobson wrote:
> 0004-pg_permissions-and-pg_ownerships.patch
Having gotten some hands-on experience of these views for a while,
I notice I quite often want to check the ownerships/permissions
for some specific type of objects, or in some specific schema.
The
New version attached.
Changes:
* Added documentation in catalogs.sgml
* Dropped "objsubid" from pg_ownerships since columns have no owner, only tables
Do we prefer "pg_permissions" or "pg_privileges"?
I can see "privileges" occur 2325 times in the sources,
while "permissions" occur only 1097 ti
On Tue, Mar 9, 2021, at 04:01, Chapman Flack wrote:
> On Sat, Mar 06, 2021 at 08:03:17PM +0100, Joel Jacobson wrote:
> >regclass | obj_desc | grantor | grantee |
> privilege_type | is_grantable
> >
> --+-+-+-+-
On 03/09/21 11:11, Joel Jacobson wrote:
> On Tue, Mar 9, 2021, at 07:34, Joel Jacobson wrote:
>> On Tue, Mar 9, 2021, at 04:01, Chapman Flack wrote:
>>> 1. Is there a reason not to make 'grantor' and 'grantee' of type regrole?
>
> Having digested your idea, I actually agree with you.
>
> Since we
On Tue, Mar 9, 2021, at 07:34, Joel Jacobson wrote:
> On Tue, Mar 9, 2021, at 04:01, Chapman Flack wrote:
>> 1. Is there a reason not to make 'grantor' and 'grantee' of type regrole?
Having digested your idea, I actually agree with you.
Since we have the regrole-type, I agree we should use it,
ev
On Tue, Mar 9, 2021, at 04:01, Chapman Flack wrote:
> On Sat, Mar 06, 2021 at 08:03:17PM +0100, Joel Jacobson wrote:
> >regclass | obj_desc | grantor | grantee |
> privilege_type | is_grantable
> >
> --+-+-+-+-
On Sat, Mar 06, 2021 at 08:03:17PM +0100, Joel Jacobson wrote:
>regclass | obj_desc | grantor | grantee |
privilege_type | is_grantable
>
--+-+-+-++--
1. Is there a reason not to make 'gran
On Mon, Mar 8, 2021, at 15:35, Joe Conway wrote:
> While this is interesting and probably useful for troubleshooting, it does not
> provide the complete picture if what you care about is something like "what
> stuff can joel do in my database".
Good point, I agree.
I think that's a different more
On 3/6/21 2:03 PM, Joel Jacobson wrote:
> ...but to answer the question...
>
> - What permissions are there for a specific role in the database?
>
> you need to manually query all relevant pg_catalog or
> information_schema.*_privileges views,
> which is a O(n) mental effort, while the first q
On Mon, Mar 8, 2021, at 07:28, Joel Jacobson wrote:
>Attached is a new patch with both pg_permissions and pg_ownerships in the same
>patch,
>based on HEAD (8a812e5106c5db50039336288d376a188844e2cc).
>
>Attachments:
>0001-pg_permissions-and-pg_ownerships.patch
I forgot to update src/test/regress/e
On Mon, Mar 8, 2021, at 02:09, David Fetter wrote:
> +1 for both this and the ownerships view.
>
> Best,
> David.
I'm glad you like it.
I've put some more effort into this patch, and developed a method to
mechanically verify its correctness.
Attached is a new patch with both pg_permissions and
On Sat, Mar 06, 2021 at 08:03:17PM +0100, Joel Jacobson wrote:
> Hi,
>
> It's easy to answer the question...
>
>- What permissions are there on this specific object?
>
> ...but to answer the question...
>
>- What permissions are there for a specific role in the database?
>
> you need t
34 matches
Mail list logo
