Re: [HACKERS] Wanting to learn about pgsql design decision

2016-08-03 Thread Kevin Grittner
On Wed, Aug 3, 2016 at 2:52 AM, Tal Walter  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


Re: [HACKERS] Wanting to learn about pgsql design decision

2016-08-03 Thread Tom Lane
Tal Walter  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


Re: [HACKERS] Wanting to learn about pgsql design decision

2016-08-03 Thread Tal Walter
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 
wrote:

> > "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

2016-08-02 Thread Andrew Gierth
> "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)


-- 
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

2016-08-02 Thread Tom Lane
Tal Walter  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


[HACKERS] Wanting to learn about pgsql design decision

2016-08-02 Thread Tal Walter
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!