Thread: Wanting to learn about pgsql design decision
Dear list,
I'm interested in pgsql, and would like to know more about the design decisions behind it's features.
Where should I search in order to know more about subjects, for example:
- Why in the roles system, user are actually roles with login attribute and not a separate entity.
- Why to read from a table, both a usage permission on the schema and a read access permission on the table is needed? Alternatively, there could be a usage permission on schema just to alter the schema itself or add tables to it, and not require it in the case of selecting from a table from inside it.
And other questions of this sort.
Thank you very much!
Thank you very much!
Tal Walter <talw@sqreamtech.com> writes:
> - Why in the roles system, user are actually roles with login attribute
> and not a separate entity.
Groups and users used to be separate concepts, actually, a long time ago.
We got rid of that because it was a PITA; in particular, grants to groups
had to be represented separately from grants to individual users. Looking
at the git history, that happened in mid-2005, so you might trawl the
pgsql-hackers archives from around that time for discussion.
> - Why to read from a table, both a usage permission on the schema and a
> read access permission on the table is needed?
Because the SQL standard says so. You might want to get a copy. While
the "official" releases cost lots o' money, draft versions are freely
available on the net, and are generally close enough.
regards, tom lane
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: >> - Why to read from a table, both a usage permission on the schema>> and a read access permission on the table is needed? Tom> Because the SQL standard says so. You'd think, but in fact it doesn't; the spec (at least 2008 and the 2011 drafts) has no concept of grantable permissions on schemas, and ties table ownership and schema ownership together. (See the definition of <privileges> to see that there's nothing there for schemas, and the definition of <table definition> for the fact that it's the schema owner who also owns the table and gets the initial grants on it, and <drop table statement> and <alter table statement> to confirm that only the schema owner can alter or drop the table. The access rules for <table reference> only require permission on a table column, no mention of schemas.) -- Andrew (irc:RhodiumToad)
<div dir="ltr">Thanks Tom and Andrew!<br />This is indeed interesting.<br /><br />Because I have a couple more of these questions,and I prefer to avoid receiving a RTFM,<br />I'd appreciate if you could help me understand how I can researchthe answers to these type of questions by myself.<br /><br />The example questions I gave are just some of the questionsI've tried to search the answer to, using google and searching this mailing list specifically, but I came up withnothing. Could I perhaps search the commit comments somehow? Or perhaps a different approach to suggest?<br /><br />Thanksfor the interesting comments and help!<br /></div><div class="gmail_extra"><br /><div class="gmail_quote">On Tue,Aug 2, 2016 at 7:43 PM, Andrew Gierth <span dir="ltr"><<a href="mailto:andrew@tao11.riddles.org.uk" target="_blank">andrew@tao11.riddles.org.uk</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>>>>> "Tom" == Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>writes:<br /><br /> >> - Why to read from a table, both ausage permission on the schema<br /> >> and a read access permission on the table is needed?<br /><br /></span> Tom>Because the SQL standard says so.<br /><br /> You'd think, but in fact it doesn't; the spec (at least 2008and the<br /> 2011 drafts) has no concept of grantable permissions on schemas, and<br /> ties table ownership and schemaownership together.<br /><br /> (See the definition of <privileges> to see that there's nothing there<br /> forschemas, and the definition of <table definition> for the fact that<br /> it's the schema owner who also owns thetable and gets the initial<br /> grants on it, and <drop table statement> and <alter table statement> to<br/> confirm that only the schema owner can alter or drop the table. The<br /> access rules for <table reference>only require permission on a table<br /> column, no mention of schemas.)<br /><span class="HOEnZb"><font color="#888888"><br/> --<br /> Andrew (irc:RhodiumToad)<br /></font></span></blockquote></div><br /></div>
Tal Walter <talw@sqreamtech.com> writes: > The example questions I gave are just some of the questions I've tried to > search the answer to, using google and searching this mailing list > specifically, but I came up with nothing. Could I perhaps search the commit > comments somehow? Or perhaps a different approach to suggest? Well, the git history is not hard to come by: pull down a copy of our git repo and see 'git log'. Also the src/tools/git_changelog script in the repo produces a nicely formatted cross-branch history. https://wiki.postgresql.org/wiki/Working_with_Git regards, tom lane
On Wed, Aug 3, 2016 at 2:52 AM, Tal Walter <talw@sqreamtech.com> wrote: > I'd appreciate if you could help me understand how I can research the > answers to these type of questions by myself. > Could I perhaps search the commit > comments somehow? Or perhaps a different approach to suggest? In addition to Tom's suggestions about how to review commit comments -- if you look in the source code directories for README files, you will find they often contain discussions of such matters. If you are up for it, the C code for implementing features also often discusses alternatives and why they were not chosen. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company