Thread: SET ROLE documentation not entirely correct
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/sql-set-role.html Description: In the course of trying to sanitise our roles and permissions I found the notes in the SET ROLE docs a little misleading: "If the session user role has the INHERITS attribute, then it automatically has all the privileges of every role that it could SET ROLE to; in this case SET ROLE effectively drops all the privileges assigned directly to the session user and to the other roles it is a member of, leaving only the privileges available to the named role." This doesn't seem to be true. Consider the following: CREATE ROLE userrole INHERIT LOGIN; CREATE ROLE usergroup NOINHERIT NOLOGIN; GRANT usergroup TO userrole; CREATE ROLE sensitive; GRANT sensitive TO usergroup; SET SESSION AUTHORIZATION userrole; SELECT session_user, current_user, rolinherit, pg_has_role('sensitive', 'USAGE') as usage, pg_has_role('sensitive', 'MEMBER') as member FROM pg_roles WHERE rolname = session_user; +--------------+--------------+------------+-------+--------+ | session_user | current_user | rolinherit | usage | member | +--------------+--------------+------------+-------+--------+ | userrole | userrole | True | False | True | +--------------+--------------+------------+-------+--------+ Here the session role 'userrole' has the INHERITS attribute, and can SET ROLE to 'sensitive', but contrary to the docs it does not automatically have the privileges associated with 'sensitive'. The intermediate 'usergroup' NOINHERIT role blocks automatic inheritance. That can be demonstrated like this: SET ROLE sensitive; SELECT session_user, current_user, rolinherit, pg_has_role('sensitive', 'USAGE') as usage, pg_has_role('sensitive', 'MEMBER') as member FROM pg_roles WHERE rolname = session_user; +--------------+--------------+------------+-------+--------+ | session_user | current_user | rolinherit | usage | member | +--------------+--------------+------------+-------+--------+ | userrole | sensitive | True | True | True | +--------------+--------------+------------+-------+--------+ (This is all on v11.2, in case it matters)
On 4/23/19 11:52 AM, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/sql-set-role.html > Description: > > In the course of trying to sanitise our roles and permissions I found the > notes in the SET ROLE docs a little misleading: > > "If the session user role has the INHERITS attribute, then it automatically > has all the privileges of every role that it could SET ROLE to; in this case > SET ROLE effectively drops all the privileges assigned directly to the > session user and to the other roles it is a member of, leaving only the > privileges available to the named role." > This doesn't seem to be true. Consider the following: Additionally s/INHERITS/INHERIT/ And similarly this sentence is wrong or at least not completely clear: 8<----------- The specified role_name must be a role that the current session user is a member of. 8<----------- The wording should be something like 8<----------- The specified role_name must be a role that the current session user is a member of directly or indirectly. 8<----------- I believe the paragraph you cite should be reworded, but I am at a loss as to how best to describe the actual situation clearly. Maybe something like: 8<----------- If the session user role has the INHERIT attribute, then it automatically has all the privileges of every role that it is a member of directly, and any that it is a member of indirectly which is not blocked by a NOINHERIT attribute of another reachable role; in this case SET ROLE effectively drops all the privileges assigned directly to the session user and to the other roles it is a member of, leaving only the privileges available to the named role. 8<----------- Thoughts? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Attachment
> Additionally s/INHERITS/INHERIT/
Good spot.
> The wording should be something like
>
> 8<-----------
> The specified role_name must be a role that the current session user is
> a member of directly or indirectly.
> 8<-----------
That’s certainly much better (perhaps with a comma after “of”, if I’m being pedantic).
> I believe the paragraph you cite should be reworded, but I am at a loss
> as to how best to describe the actual situation clearly. Maybe something
> like:
>
> 8<-----------
> If the session user role has the INHERIT attribute, then it
> automatically has all the privileges of every role that it is a member
> of directly, and any that it is a member of indirectly which is not
> blocked by a NOINHERIT attribute of another reachable role; in this case
> SET ROLE effectively drops all the privileges assigned directly to the
> session user and to the other roles it is a member of, leaving only the
> privileges available to the named role.
> 8<-----------
>
> Thoughts?
Again, that's much clearer than what is currently there. It might help if some of the language/definitions from pg_has_role() is used, though.
For example:
A role X is a "MEMBER" of another role Y if there is a chain of GRANTs from X to Y via zero or more intermediate roles. This allows X to execute "SET ROLE Y".
Additionally X has "USAGE" of Y if X and all the intermediate roles (but *not* necessarily Y) are marked INHERIT. In this case X automatically has the privileges of Y, without the need to "SET ROLE Y".
Just my 2p, but being fairly new to postgres' roles and privilege set-up I can tell you that the things I have found difficult, but important, to get my head around are:
* A role either pulls in all privileges it can (INHERIT) or none at all (NOINHERIT). It is not possible to create a role that all direct members are guaranteed to require, or not require, a "SET ROLE" to use (i.e. you can't mark a role as "inheritable" or "not inheritable")
* A role's attributes are not inherited by its members - SUPERUSER, CREATEROLE, etc. The CREATE ROLE docs refer to these things as both "attributes" and "privileges", which is a bit unhelpful. It would be better to refer to them only as "attributes" everywhere, so it is clear that "attributes" are never inherited whereas "privileges" can be inherited.
* As mentioned above, "X is a member of Y" implies "X can SET ROLE Y". Membership requires a GRANT chain from X to Y.
* Also mentioned above, "X has usage of Y" implies "X doesn't need to SET ROLE Y, other than to use Y's attributes". Usage requires everything apart from Y in the GRANT chain to be marked INHERIT.
Is there the ability to include diagrams or other images in the postgres docs? I think it could really help. Boxes for roles, arrows for membership - pointing from group to member (to show the flow of privileges), with a solid line if the member has INHERIT and a broken line if they have NOINHERIT... that sort of thing.
Steve.
This email is confidential. If you are not the intended recipient, please advise us immediately and delete this message. The registered name of Cantab- part of GAM Systematic is Cantab Capital Partners LLP. See - http://www.gam.com/en/Legal/Email+disclosures+EU for further information on confidentiality, the risks of non-secure electronic communication, and certain disclosures which we are required to make in accordance with applicable legislation and regulations. If you cannot access this link, please notify us by reply message and we will send the contents to you.
GAM Holding AG and its subsidiaries (Cantab – GAM Systematic) will collect and use information about you in the course of your interactions with us. Full details about the data types we collect and what we use this for and your related rights is set out in our online privacy policy at https://www.gam.com/en/legal/privacy-policy. Please familiarise yourself with this policy and check it from time to time for updates as it supplements this notice
Good spot.
> The wording should be something like
>
> 8<-----------
> The specified role_name must be a role that the current session user is
> a member of directly or indirectly.
> 8<-----------
That’s certainly much better (perhaps with a comma after “of”, if I’m being pedantic).
> I believe the paragraph you cite should be reworded, but I am at a loss
> as to how best to describe the actual situation clearly. Maybe something
> like:
>
> 8<-----------
> If the session user role has the INHERIT attribute, then it
> automatically has all the privileges of every role that it is a member
> of directly, and any that it is a member of indirectly which is not
> blocked by a NOINHERIT attribute of another reachable role; in this case
> SET ROLE effectively drops all the privileges assigned directly to the
> session user and to the other roles it is a member of, leaving only the
> privileges available to the named role.
> 8<-----------
>
> Thoughts?
Again, that's much clearer than what is currently there. It might help if some of the language/definitions from pg_has_role() is used, though.
For example:
A role X is a "MEMBER" of another role Y if there is a chain of GRANTs from X to Y via zero or more intermediate roles. This allows X to execute "SET ROLE Y".
Additionally X has "USAGE" of Y if X and all the intermediate roles (but *not* necessarily Y) are marked INHERIT. In this case X automatically has the privileges of Y, without the need to "SET ROLE Y".
Just my 2p, but being fairly new to postgres' roles and privilege set-up I can tell you that the things I have found difficult, but important, to get my head around are:
* A role either pulls in all privileges it can (INHERIT) or none at all (NOINHERIT). It is not possible to create a role that all direct members are guaranteed to require, or not require, a "SET ROLE" to use (i.e. you can't mark a role as "inheritable" or "not inheritable")
* A role's attributes are not inherited by its members - SUPERUSER, CREATEROLE, etc. The CREATE ROLE docs refer to these things as both "attributes" and "privileges", which is a bit unhelpful. It would be better to refer to them only as "attributes" everywhere, so it is clear that "attributes" are never inherited whereas "privileges" can be inherited.
* As mentioned above, "X is a member of Y" implies "X can SET ROLE Y". Membership requires a GRANT chain from X to Y.
* Also mentioned above, "X has usage of Y" implies "X doesn't need to SET ROLE Y, other than to use Y's attributes". Usage requires everything apart from Y in the GRANT chain to be marked INHERIT.
Is there the ability to include diagrams or other images in the postgres docs? I think it could really help. Boxes for roles, arrows for membership - pointing from group to member (to show the flow of privileges), with a solid line if the member has INHERIT and a broken line if they have NOINHERIT... that sort of thing.
Steve.
This email is confidential. If you are not the intended recipient, please advise us immediately and delete this message. The registered name of Cantab- part of GAM Systematic is Cantab Capital Partners LLP. See - http://www.gam.com/en/Legal/Email+disclosures+EU for further information on confidentiality, the risks of non-secure electronic communication, and certain disclosures which we are required to make in accordance with applicable legislation and regulations. If you cannot access this link, please notify us by reply message and we will send the contents to you.
GAM Holding AG and its subsidiaries (Cantab – GAM Systematic) will collect and use information about you in the course of your interactions with us. Full details about the data types we collect and what we use this for and your related rights is set out in our online privacy policy at https://www.gam.com/en/legal/privacy-policy. Please familiarise yourself with this policy and check it from time to time for updates as it supplements this notice
On 4/25/19 11:25 AM, Steven Winfield wrote: >> Additionally s/INHERITS/INHERIT/ > > Good spot. > >> The wording should be something like >> >> 8<----------- >> The specified role_name must be a role that the current session user is >> a member of directly or indirectly. >> 8<----------- > > That’s certainly much better (perhaps with a comma after “of”, if I’m > being pedantic). > >> I believe the paragraph you cite should be reworded, but I am at a loss >> as to how best to describe the actual situation clearly. Maybe something >> like: >> >> 8<----------- >> If the session user role has the INHERIT attribute, then it >> automatically has all the privileges of every role that it is a member >> of directly, and any that it is a member of indirectly which is not >> blocked by a NOINHERIT attribute of another reachable role; in this case >> SET ROLE effectively drops all the privileges assigned directly to the >> session user and to the other roles it is a member of, leaving only the >> privileges available to the named role. >> 8<----------- >> >> Thoughts? > > Again, that's much clearer than what is currently there. It might help > if some of the language/definitions from pg_has_role() is used, though. > > For example: > A role X is a "MEMBER" of another role Y if there is a chain of GRANTs > from X to Y via zero or more intermediate roles. This allows X to > execute "SET ROLE Y". > Additionally X has "USAGE" of Y if X and all the intermediate roles (but > *not* necessarily Y) are marked INHERIT. In this case X automatically > has the privileges of Y, without the need to "SET ROLE Y". > > > Just my 2p, but being fairly new to postgres' roles and privilege set-up > I can tell you that the things I have found difficult, but important, to > get my head around are: > > * A role either pulls in all privileges it can (INHERIT) or none at all > (NOINHERIT). It is not possible to create a role that all direct members > are guaranteed to require, or not require, a "SET ROLE" to use (i.e. you > can't mark a role as "inheritable" or "not inheritable") > > * A role's attributes are not inherited by its members - SUPERUSER, > CREATEROLE, etc. The CREATE ROLE docs refer to these things as both > "attributes" and "privileges", which is a bit unhelpful. It would be > better to refer to them only as "attributes" everywhere, so it is clear > that "attributes" are never inherited whereas "privileges" can be inherited. > > * As mentioned above, "X is a member of Y" implies "X can SET ROLE Y". > Membership requires a GRANT chain from X to Y. > > * Also mentioned above, "X has usage of Y" implies "X doesn't need to > SET ROLE Y, other than to use Y's attributes". Usage requires everything > apart from Y in the GRANT chain to be marked INHERIT. All good stuff. I will try to take this into account and submit an actual proposed patch -- hopefully over this weekend. > Is there the ability to include diagrams or other images in the postgres > docs? I think it could really help. Boxes for roles, arrows for > membership - pointing from group to member (to show the flow of > privileges), with a solid line if the member has INHERIT and a broken > line if they have NOINHERIT... that sort of thing. We *just* very recently added the ability to add images. Not sure I want to attempt creating one for this, but perhaps after I write the patch you could give it a go with an image to match your thoughts? By the way, I wrote an extension to aid in sorting this stuff out -- you might want to have a look: https://github.com/CrunchyData/crunchy_check_access Feedback welcomed. Patches even more so ;-) Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Attachment
> All good stuff. I will try to take this into account and submit an
> actual proposed patch -- hopefully over this weekend.
Thanks.
> We *just* very recently added the ability to add images. Not sure I want
> to attempt creating one for this, but perhaps after I write the patch
> you could give it a go with an image to match your thoughts?
That's great. Is there a page somewhere with a styling guide - preferred RGB values, fonts, allowable bitmap and/or vector formats... that sort of thing?
> By the way, I wrote an extension to aid in sorting this stuff out -- you
> might want to have a look:
>
> https://github.com/CrunchyData/crunchy_check_access
>
> Feedback welcomed. Patches even more so ;-)
Nice - will definitely have a look.
Steve.
This email is confidential. If you are not the intended recipient, please advise us immediately and delete this message. The registered name of Cantab- part of GAM Systematic is Cantab Capital Partners LLP. See - http://www.gam.com/en/Legal/Email+disclosures+EU for further information on confidentiality, the risks of non-secure electronic communication, and certain disclosures which we are required to make in accordance with applicable legislation and regulations. If you cannot access this link, please notify us by reply message and we will send the contents to you.
GAM Holding AG and its subsidiaries (Cantab – GAM Systematic) will collect and use information about you in the course of your interactions with us. Full details about the data types we collect and what we use this for and your related rights is set out in our online privacy policy at https://www.gam.com/en/legal/privacy-policy. Please familiarise yourself with this policy and check it from time to time for updates as it supplements this notice
> actual proposed patch -- hopefully over this weekend.
Thanks.
> We *just* very recently added the ability to add images. Not sure I want
> to attempt creating one for this, but perhaps after I write the patch
> you could give it a go with an image to match your thoughts?
That's great. Is there a page somewhere with a styling guide - preferred RGB values, fonts, allowable bitmap and/or vector formats... that sort of thing?
> By the way, I wrote an extension to aid in sorting this stuff out -- you
> might want to have a look:
>
> https://github.com/CrunchyData/crunchy_check_access
>
> Feedback welcomed. Patches even more so ;-)
Nice - will definitely have a look.
Steve.
This email is confidential. If you are not the intended recipient, please advise us immediately and delete this message. The registered name of Cantab- part of GAM Systematic is Cantab Capital Partners LLP. See - http://www.gam.com/en/Legal/Email+disclosures+EU for further information on confidentiality, the risks of non-secure electronic communication, and certain disclosures which we are required to make in accordance with applicable legislation and regulations. If you cannot access this link, please notify us by reply message and we will send the contents to you.
GAM Holding AG and its subsidiaries (Cantab – GAM Systematic) will collect and use information about you in the course of your interactions with us. Full details about the data types we collect and what we use this for and your related rights is set out in our online privacy policy at https://www.gam.com/en/legal/privacy-policy. Please familiarise yourself with this policy and check it from time to time for updates as it supplements this notice
On 4/25/19 12:39 PM, Steven Winfield wrote: >> We *just* very recently added the ability to add images. Not sure I want >> to attempt creating one for this, but perhaps after I write the patch >> you could give it a go with an image to match your thoughts? > > That's great. Is there a page somewhere with a styling guide - preferred > RGB values, fonts, allowable bitmap and/or vector formats... that sort > of thing? There is a documentation style guide (of sorts) here: https://www.postgresql.org/docs/devel/docguide-style.html But it has nothing from what I can see to say about images. FWIW, I believe images need to be svg format, but I am not entirely sure of that. There is also nothing I could find quickly searching through the docs which describes how to insert images into the documentation. There is one image which can be used as an example though: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD Likely both of those omissions should be fixed... Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Attachment
On 4/25/19 1:08 PM, Joe Conway wrote: > There is one image which can be used as an example though: > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD Here is a more precise URL: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD#l934 Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Attachment
Joe Conway <mail@joeconway.com> writes: > On 4/25/19 1:08 PM, Joe Conway wrote: >> There is one image which can be used as an example though: >> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD > Here is a more precise URL: > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD#l934 Comparing that to what I see at https://www.postgresql.org/docs/devel/storage-page-layout.html does not lead to a warm feeling about our images-in-docs stuff really being ready for prime time. It works OK in some browsers but others (at least Safari) cut off the image. regards, tom lane
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > Joe Conway <mail@joeconway.com> writes: > > On 4/25/19 1:08 PM, Joe Conway wrote: > >> There is one image which can be used as an example though: > >> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD > > > Here is a more precise URL: > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD#l934 > > Comparing that to what I see at > > https://www.postgresql.org/docs/devel/storage-page-layout.html > > does not lead to a warm feeling about our images-in-docs stuff > really being ready for prime time. It works OK in some browsers > but others (at least Safari) cut off the image. Yeah, I'm seeing it cut off in Chrome too, initially, and then it seems to fix itself if I resize the window down from 4k (and stay fixed even if I then go back to the original, much larger, size). That seems like a CSS or layout issue though, not an issue with the image itself..? Thanks! Stephen
Attachment
On 4/25/19 3:06 PM, Stephen Frost wrote: > Greetings, > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> Joe Conway <mail@joeconway.com> writes: >> > On 4/25/19 1:08 PM, Joe Conway wrote: >> >> There is one image which can be used as an example though: >> >> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD >> >> > Here is a more precise URL: >> > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD#l934 >> >> Comparing that to what I see at >> >> https://www.postgresql.org/docs/devel/storage-page-layout.html >> >> does not lead to a warm feeling about our images-in-docs stuff >> really being ready for prime time. It works OK in some browsers >> but others (at least Safari) cut off the image. > > Yeah, I'm seeing it cut off in Chrome too, initially, and then it seems > to fix itself if I resize the window down from 4k (and stay fixed even > if I then go back to the original, much larger, size). That seems like > a CSS or layout issue though, not an issue with the image itself..? Yeah, I see the same thing in Chrome -- maybe Jonathan has an idea what is going on and how to best fix it? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Attachment
On 4/25/19 3:20 PM, Joe Conway wrote: > On 4/25/19 3:06 PM, Stephen Frost wrote: >> Greetings, >> >> * Tom Lane (tgl@sss.pgh.pa.us) wrote: >>> Joe Conway <mail@joeconway.com> writes: >>>> On 4/25/19 1:08 PM, Joe Conway wrote: >>>>> There is one image which can be used as an example though: >>>>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD >>> >>>> Here is a more precise URL: >>>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD#l934 >>> >>> Comparing that to what I see at >>> >>> https://www.postgresql.org/docs/devel/storage-page-layout.html >>> >>> does not lead to a warm feeling about our images-in-docs stuff >>> really being ready for prime time. It works OK in some browsers >>> but others (at least Safari) cut off the image. >> >> Yeah, I'm seeing it cut off in Chrome too, initially, and then it seems >> to fix itself if I resize the window down from 4k (and stay fixed even >> if I then go back to the original, much larger, size). That seems like >> a CSS or layout issue though, not an issue with the image itself..? > > > Yeah, I see the same thing in Chrome -- maybe Jonathan has an idea what > is going on and how to best fix it? See[1] - I'm not sure if the final piece is committed -- if when it is I can finish fixing the pgweb part. Jonathan [1] https://www.postgresql.org/message-id/flat/6d2442d1-84a2-36ef-e014-b6d1ece8a139%40postgresql.org
Attachment
On 4/25/19 4:52 PM, Jonathan S. Katz wrote: > On 4/25/19 3:20 PM, Joe Conway wrote: >> On 4/25/19 3:06 PM, Stephen Frost wrote: >>> Greetings, >>> >>> * Tom Lane (tgl@sss.pgh.pa.us) wrote: >>>> Joe Conway <mail@joeconway.com> writes: >>>>> On 4/25/19 1:08 PM, Joe Conway wrote: >>>>>> There is one image which can be used as an example though: >>>>>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD >>>> >>>>> Here is a more precise URL: >>>>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD#l934 >>>> >>>> Comparing that to what I see at >>>> >>>> https://www.postgresql.org/docs/devel/storage-page-layout.html >>>> >>>> does not lead to a warm feeling about our images-in-docs stuff >>>> really being ready for prime time. It works OK in some browsers >>>> but others (at least Safari) cut off the image. >>> >>> Yeah, I'm seeing it cut off in Chrome too, initially, and then it seems >>> to fix itself if I resize the window down from 4k (and stay fixed even >>> if I then go back to the original, much larger, size). That seems like >>> a CSS or layout issue though, not an issue with the image itself..? >> >> >> Yeah, I see the same thing in Chrome -- maybe Jonathan has an idea what >> is going on and how to best fix it? > > See[1] - I'm not sure if the final piece is committed -- if when it is I > can finish fixing the pgweb part OK, so I took a quick look at the existing SVGs with my patched version of pgweb. The short answer is that it's better: the SVGs are not responsive, but they are displaying. There still needs to be work on the SVGs as indicated in that thread to make them responsive[1]. With that said, the pgweb patch does fix their current display at least in full view, so I pushed the current patch to pgweb to do that. The fix will take effect the next time the nightly docload runs, or if someone on pginfra forces it to occur more quickly. Thanks, Jonathan [1] https://www.postgresql.org/message-id/flat/6d2442d1-84a2-36ef-e014-b6d1ece8a139%40postgresql.org
Attachment
On 4/25/19 5:22 PM, Jonathan S. Katz wrote: > On 4/25/19 4:52 PM, Jonathan S. Katz wrote: >> On 4/25/19 3:20 PM, Joe Conway wrote: >>> On 4/25/19 3:06 PM, Stephen Frost wrote: >>>> Yeah, I'm seeing it cut off in Chrome too, initially, and then it seems >>>> to fix itself if I resize the window down from 4k (and stay fixed even >>>> if I then go back to the original, much larger, size). That seems like >>>> a CSS or layout issue though, not an issue with the image itself..? >>> >>> Yeah, I see the same thing in Chrome -- maybe Jonathan has an idea what >>> is going on and how to best fix it? >> >> See[1] - I'm not sure if the final piece is committed -- if when it is I >> can finish fixing the pgweb part > OK, so I took a quick look at the existing SVGs with my patched version > of pgweb. > > The short answer is that it's better: the SVGs are not responsive, but > they are displaying. There still needs to be work on the SVGs as > indicated in that thread to make them responsive[1]. > [1] > https://www.postgresql.org/message-id/flat/6d2442d1-84a2-36ef-e014-b6d1ece8a139%40postgresql.org Is there any written instruction anywhere with guidance on how the SVGs should be made? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
On 4/25/19 5:22 PM, Jonathan S. Katz wrote: > On 4/25/19 4:52 PM, Jonathan S. Katz wrote: >> On 4/25/19 3:20 PM, Joe Conway wrote: >>> On 4/25/19 3:06 PM, Stephen Frost wrote: >>>> Greetings, >>>> >>>> * Tom Lane (tgl@sss.pgh.pa.us) wrote: >>>>> Joe Conway <mail@joeconway.com> writes: >>>>>> On 4/25/19 1:08 PM, Joe Conway wrote: >>>>>>> There is one image which can be used as an example though: >>>>>>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD >>>>> >>>>>> Here is a more precise URL: >>>>>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/storage.sgml;hb=HEAD#l934 >>>>> >>>>> Comparing that to what I see at >>>>> >>>>> https://www.postgresql.org/docs/devel/storage-page-layout.html >>>>> >>>>> does not lead to a warm feeling about our images-in-docs stuff >>>>> really being ready for prime time. It works OK in some browsers >>>>> but others (at least Safari) cut off the image. >>>> >>>> Yeah, I'm seeing it cut off in Chrome too, initially, and then it seems >>>> to fix itself if I resize the window down from 4k (and stay fixed even >>>> if I then go back to the original, much larger, size). That seems like >>>> a CSS or layout issue though, not an issue with the image itself..? >>> >>> >>> Yeah, I see the same thing in Chrome -- maybe Jonathan has an idea what >>> is going on and how to best fix it? >> >> See[1] - I'm not sure if the final piece is committed -- if when it is I >> can finish fixing the pgweb part > OK, so I took a quick look at the existing SVGs with my patched version > of pgweb. > > The short answer is that it's better: the SVGs are not responsive, but > they are displaying. There still needs to be work on the SVGs as > indicated in that thread to make them responsive[1]. > > With that said, the pgweb patch does fix their current display at least > in full view, so I pushed the current patch to pgweb to do that. The fix > will take effect the next time the nightly docload runs, or if someone > on pginfra forces it to occur more quickly. Good news - I did test against an older snapshot. With a newer snapshot, the SVG on the GIN implementation page[1] is responsive but not the one on the storage page layout[2], which is what the proposed fix in the other thread handles. Jonathan [1] https://www.postgresql.org/docs/devel/gin-implementation.html [2] https://www.postgresql.org/docs/devel/storage-page-layout.html
Attachment
On 4/25/19 5:26 PM, Joe Conway wrote: > > Is there any written instruction anywhere with guidance on how the SVGs > should be made? https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/images/README; but I would suggest we had some guidance on how to ensure the image stays scalable. Jonathan
Attachment
On 4/25/19 5:59 PM, Jonathan S. Katz wrote: > On 4/25/19 5:26 PM, Joe Conway wrote: >> >> Is there any written instruction anywhere with guidance on how the SVGs >> should be made? > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/images/README; Awesome -- that is what I had been looking for. Shouldn't we add that to the actual documentation style guide? > but I would suggest we had some guidance on how to ensure the image > stays scalable. Since you seem to know the magic incarnations, can you propose some words? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
On 4/25/19 6:54 PM, Joe Conway wrote: > On 4/25/19 5:59 PM, Jonathan S. Katz wrote: >> On 4/25/19 5:26 PM, Joe Conway wrote: >>> >>> Is there any written instruction anywhere with guidance on how the SVGs >>> should be made? >> >> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/images/README; > > Awesome -- that is what I had been looking for. Shouldn't we add that to > the actual documentation style guide? > >> but I would suggest we had some guidance on how to ensure the image >> stays scalable. > > Since you seem to know the magic incarnations, can you propose some words? Please see attached. Jonathan
Attachment
On 4/26/19 3:04 PM, Jonathan S. Katz wrote: > On 4/25/19 6:54 PM, Joe Conway wrote: >> On 4/25/19 5:59 PM, Jonathan S. Katz wrote: >>> On 4/25/19 5:26 PM, Joe Conway wrote: >>>> >>>> Is there any written instruction anywhere with guidance on how the SVGs >>>> should be made? >>> >>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/images/README; >> >> Awesome -- that is what I had been looking for. Shouldn't we add that to >> the actual documentation style guide? >> >>> but I would suggest we had some guidance on how to ensure the image >>> stays scalable. >> >> Since you seem to know the magic incarnations, can you propose some words? > > Please see attached. v2 -- fixed typo in height, and modified some of the language. Jonathan
Attachment
On 4/26/19 3:14 PM, Jonathan S. Katz wrote: > On 4/26/19 3:04 PM, Jonathan S. Katz wrote: >> On 4/25/19 6:54 PM, Joe Conway wrote: >>> On 4/25/19 5:59 PM, Jonathan S. Katz wrote: >>>> On 4/25/19 5:26 PM, Joe Conway wrote: >>>>> >>>>> Is there any written instruction anywhere with guidance on how the SVGs >>>>> should be made? >>>> >>>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/images/README; >>> >>> Awesome -- that is what I had been looking for. Shouldn't we add that to >>> the actual documentation style guide? >>> >>>> but I would suggest we had some guidance on how to ensure the image >>>> stays scalable. >>> >>> Since you seem to know the magic incarnations, can you propose some words? >> >> Please see attached. > > v2 -- fixed typo in height, and modified some of the language. Pushed with a bit of editorialization. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
On 4/25/19 5:58 PM, Jonathan S. Katz wrote: > Good news - I did test against an older snapshot. With a newer snapshot, > the SVG on the GIN implementation page[1] is responsive but not the one > on the storage page layout[2], which is what the proposed fix in the > other thread handles. > [2] https://www.postgresql.org/docs/devel/storage-page-layout.html I pushed that change too. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
On 4/25/19 11:25 AM, Steven Winfield wrote: > Again, that's much clearer than what is currently there. It might help > if some of the language/definitions from pg_has_role() is used, though. > > For example: > A role X is a "MEMBER" of another role Y if there is a chain of GRANTs > from X to Y via zero or more intermediate roles. This allows X to > execute "SET ROLE Y". > Additionally X has "USAGE" of Y if X and all the intermediate roles (but > *not* necessarily Y) are marked INHERIT. In this case X automatically > has the privileges of Y, without the need to "SET ROLE Y". I've been whacking this around for the better part of the afternoon and came up with the attached. I think it is correct, and better than my previous proposal, but possibly need more polish. Comments welcome. > * A role's attributes are not inherited by its members - SUPERUSER, > CREATEROLE, etc. The CREATE ROLE docs refer to these things as both > "attributes" and "privileges", which is a bit unhelpful. It would be > better to refer to them only as "attributes" everywhere, so it is clear > that "attributes" are never inherited whereas "privileges" can be inherited. Sounds reasonable but probably a separate patch. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Attachment
> I've been whacking this around for the better part of the afternoon and
> came up with the attached. I think it is correct, and better than my
> previous proposal, but possibly need more polish. Comments welcome.
FWIW it looks good to me!
Steve.
This email is confidential. If you are not the intended recipient, please advise us immediately and delete this message. The registered name of Cantab- part of GAM Systematic is Cantab Capital Partners LLP. See - http://www.gam.com/en/Legal/Email+disclosures+EU for further information on confidentiality, the risks of non-secure electronic communication, and certain disclosures which we are required to make in accordance with applicable legislation and regulations. If you cannot access this link, please notify us by reply message and we will send the contents to you.
GAM Holding AG and its subsidiaries (Cantab – GAM Systematic) will collect and use information about you in the course of your interactions with us. Full details about the data types we collect and what we use this for and your related rights is set out in our online privacy policy at https://www.gam.com/en/legal/privacy-policy. Please familiarise yourself with this policy and check it from time to time for updates as it supplements this notice
> came up with the attached. I think it is correct, and better than my
> previous proposal, but possibly need more polish. Comments welcome.
FWIW it looks good to me!
Steve.
This email is confidential. If you are not the intended recipient, please advise us immediately and delete this message. The registered name of Cantab- part of GAM Systematic is Cantab Capital Partners LLP. See - http://www.gam.com/en/Legal/Email+disclosures+EU for further information on confidentiality, the risks of non-secure electronic communication, and certain disclosures which we are required to make in accordance with applicable legislation and regulations. If you cannot access this link, please notify us by reply message and we will send the contents to you.
GAM Holding AG and its subsidiaries (Cantab – GAM Systematic) will collect and use information about you in the course of your interactions with us. Full details about the data types we collect and what we use this for and your related rights is set out in our online privacy policy at https://www.gam.com/en/legal/privacy-policy. Please familiarise yourself with this policy and check it from time to time for updates as it supplements this notice
On 4/27/19 4:02 PM, Joe Conway wrote: > On 4/25/19 11:25 AM, Steven Winfield wrote: >> Again, that's much clearer than what is currently there. It might help >> if some of the language/definitions from pg_has_role() is used, though. >> >> For example: >> A role X is a "MEMBER" of another role Y if there is a chain of GRANTs >> from X to Y via zero or more intermediate roles. This allows X to >> execute "SET ROLE Y". >> Additionally X has "USAGE" of Y if X and all the intermediate roles (but >> *not* necessarily Y) are marked INHERIT. In this case X automatically >> has the privileges of Y, without the need to "SET ROLE Y". > > I've been whacking this around for the better part of the afternoon and > came up with the attached. I think it is correct, and better than my > previous proposal, but possibly need more polish. Comments welcome. I've been sitting on this change a while and want to get it pushed. Steven Winfield seemed happy with it -- any other comments before I commit? Also this seems like it ought to be back-patched, but any thoughts on that? Thanks, Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development