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!
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 Gierth <andrew@tao11.riddles.org.uk>
wrote:
Show quoted text
"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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers