Re: "System roles" mentioned in psql documentation
On 24.08.2018 02:21, Michael Paquier wrote: On Thu, Aug 23, 2018 at 10:53:35AM +0200, Jürgen Purtz wrote: This inconsistency is part of the more general problem that we miss a chapter, where our basic terms like 'database', 'cluster', 'segment', 'catalog', 'schema', ... are explicitly defined. You may have a point here, not in the way of reworking entirely the documentation, but in the fact that we may want to use "system objects" instead of "system roles". I am not personally sure that it is a better improvement than using "default roles", but that's a point to raise. -- Michael First, the intention of my note was to improve the complete documentation by defining the meaning of important terms in a separate chapter. The discussion about "system roles" and "default roles" is only one of many points where we use terms in a fuzzy way. Second (and this seems to be the point of your mail), the term "role" is loosely described at the beginning of chapter 21 "A role can be thought of as either a database user, or ... ". In contrast to this description chapter 21.5 and table 21.1. use the term "role" very differently. Here it is used in the sense of a "capability", a "right", a "permission", an "allowed access" ... . This cumulates in the example at the bottom: "GRANT pg_signal_backend TO admin_user;" What is the "role", the "pg_signal_backend" or the "admin_user"? Kind regards Jürgen Purtz
Re: Enhancing protocol.sgml
On 2018-07-27, Tatsuo Ishii wrote ... > ... I think this should be mentioned in protocol.sgml as well. ... I agree. It is already mentioned as one of the differences between v2 and v3 but an implementer should not need to read that section if they are only implementing v3. (I know I've never looked at it before.) Using protocol.diff as a base, I changed the phrasing to be more prescriptive for v3 protocol implementers (don't send a final line, be prepared to receive a final line), changed passive voice to active voice and fixed one COPYData -> CopyData capitalization. I also called this out in the description of the CopyData message format because that is where the termination line would be transmitted. protocol.v2.patch Description: Binary data
Re: Global dict name is listed inconsistently
On Tue, Aug 21, 2018 at 09:17:35AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/static/plpython-sharing.html > Description: > > Page https://www.postgresql.org/docs/10/static/plpython-sharing.html says: > "The global dictionary SD is available to store data between function > calls." few lines lower it says: "global data and function arguments from > myfunc are not available to myfunc2. The exception is the data in the GD > dictionary, as mentioned above." Note that the global dictionary is named > "SD" in the first quote and "GD" in the second one. > > Please correct either first or second sentence. Well, the documentation is correct, but obviously not clear. I have the attached patch which modifies the documentation and clarifies this issue. Does it help you? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml new file mode 100644 index d086ddf..60a5907 *** a/doc/src/sgml/plpython.sgml --- b/doc/src/sgml/plpython.sgml *** SELECT * FROM multiout_simple_setof(3); *** 768,776 Sharing Data The global dictionary SD is available to store !data between function calls. This variable is private static data. The global dictionary GD is public data, !available to all Python functions within a session. Use with care.global data in PL/Python --- 768,776 Sharing Data The global dictionary SD is available to store !private data between repeated calls to the same function. The global dictionary GD is public data, !that is available to all Python functions within a session; use with care.global data in PL/Python
Re: Documentation does not cover multiple WITH in one query
On Wed, Aug 22, 2018 at 09:24:52AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/static/queries-with.html > Description: > > Hi. I have found > [DOC](https://www.postgresql.org/docs/10/static/queries-with.html) > > it is fine, but did not cover multiple WITH in one query. > > I found answer only [here](https://stackoverflow.com/a/38137037/4632019) > > May you please add the example: > > WITH table1 AS (...), table2 AS (...) SELECT * FROM table1, table2 Well, the SELECT manual has: [ WITH [ RECURSIVE ] with_query [, ...] ] and with_query is shown as: with_query_name [ ( column_name [, ...] ) ] AS ( select | values | insert | update | delete ) This is standard SQL. I don't think we are going to be able to show every possible syntax. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: fix word
On Thu, Aug 23, 2018 at 05:56:16AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/static/app-pg-ctl.html > Description: > > ref/pg_ctl-ref.sgml > 337,338c337,339 > < The options should usually be surrounded by single > or > < double quotes to ensure that they are passed through as a group. > --- > > The initdb-options should usually be surrounded > > by single or double quotes to ensure that they are passed > through > > as a group. I see your point. We call 'postgres' binary options 'options' and we call initdb-mode options 'initdb-options' in the -o title, but not in the paragraph. I assume we want to keep calling the former simply 'options'. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
