Обсуждение: 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)
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!
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 Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>> "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)
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