Re: [HACKERS] Wanting to learn about pgsql design decision
On Wed, Aug 3, 2016 at 2:52 AM, Tal Walterwrote: > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Wanting to learn about pgsql design decision
Tal Walterwrites: > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Wanting to learn about pgsql design decision
Thanks Tom and Andrew! This is indeed interesting. Because I have a couple more of these questions, and I prefer to avoid receiving a RTFM, I'd appreciate if you could help me understand how I can research the answers to these type of questions by myself. 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? Thanks for the interesting comments and help! On Tue, Aug 2, 2016 at 7:43 PM, Andrew Gierthwrote: > > "Tom" == Tom Lane 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 to see that there's nothing there > for schemas, and the definition of for the fact that > it's the schema owner who also owns the table and gets the initial > grants on it, and and to > confirm that only the schema owner can alter or drop the table. The > access rules for only require permission on a table > column, no mention of schemas.) > > -- > Andrew (irc:RhodiumToad) >
Re: [HACKERS] Wanting to learn about pgsql design decision
> "Tom" == Tom Lanewrites: >> - 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 to see that there's nothing there for schemas, and the definition of for the fact that it's the schema owner who also owns the table and gets the initial grants on it, and and to confirm that only the schema owner can alter or drop the table. The access rules for only require permission on a table column, no mention of schemas.) -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Wanting to learn about pgsql design decision
Tal Walterwrites: >- 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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!