https://www.postgresql.org/download/linux/ubuntu/
Hi Please upgrade PostgreSQL document to latest version https://www.postgresql.org/download/linux/ubuntu/ Change apt-get install postgresql-9.6 > postgresql-10 Thanks, Indrek
GRANT and REVOKE grammar.
Hi all.The way it is described in the documentation for GRANT syntax (https://www.postgresql.org/docs/10/static/sql-grant.html end all prior versions) doesn't look quite right. According to the doc, something like that shouldn't be possible: GRANT SELECT(field), TRUNCATE, INSERT(abc) ON TABLE foobar TO alexey, namely mixing privileges with column name in parens (eg. INSERT(abc)) and without (eg. TRUNCATE) in the same GRANT statement, but clearly it is correct syntax.So instead of current grammar in the doc:GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] table_name [, ...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
ON [ TABLE ] table_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
I suggest it should be:GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON { ALL TABLES IN SCHEMA schema_name [, ...] }
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { { { SELECT | INSERT | UPDATE | REFERENCES } [ ( column_name [, ...] ) ]
| { DELETE | TRUNCATE | TRIGGER } }
[, ...] | ALL [ PRIVILEGES ] [ ( column_name [, ...] ) ] }
ON [ TABLE ] table_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
Does it make sense, or am I tripping?Alternatively it could be:GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] table_name [, ...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
TO role_specification [, ...] [ WITH GRANT OPTION ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } [ ( column_name [, ...] ) ]
[, ...] | ALL [ PRIVILEGES ] [ ( column_name [, ...] ) ] }
ON [ TABLE ] table_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]
Note the [] around [ ( column_name [, ...] ) ], but the former is a bit clearer, I think.Identical issue and solution applies to REVOKE syntax: https://www.postgresql.org/docs/10/static/sql-revoke.htmlForgive me if I am wrong, not a daily PostgreSQL user. Thank you.Alexey.
Extra indentation in first line
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/10/static/textsearch-features.html
Description:
Hello,
In some queries there is an extra indentation. For example:
SELECT to_tsquery('fat') <-> to_tsquery('cat | rat');
?column?
---
'fat' <-> 'cat' | 'fat' <-> 'rat'
But there are no indentation (it's correct) here:
SELECT ts_rewrite('a & b'::tsquery,
'SELECT t,s FROM aliases WHERE ''a & b''::tsquery @>
t');
ts_rewrite
'b' & 'c'
It seems that there are no such indentations within .sgml files.
Re: Extra indentation in first line
On Mon, Feb 26, 2018 at 6:43 AM, PG Doc comments form < nore...@postgresql.org> wrote: > In some queries there is an extra indentation > . > I just now noticed the same thing while looking a report on GRANT syntax. I've spotted checked a couple of other pages and found the same. The "code" blocks housing examples sometimes has extra leading whitespace (indentation). We have recently switched to new tooling around the documentation so this appearing now is not that surprising though I don't recall any recent changes and this is the first report of such behavior I've seen. David J.
Re: Images in the official documentation
Craig Ringer writes: > On 26 February 2018 at 12:16, Tom Lane wrote: >> How can we resolve these issues? > Question the assumptions and requirements. Why do we actually _need_ > diffable, mergeable images? Sure, it'd be *nice*, but what's the real world > impact if we don't have it? Well, I'll tell you exactly why I'm being sticky about this: we've been down this road before. We used to have some figures in .gif format, and one of the problems with them was they were too hard to update. I don't buy the "they won't need updates" argument for a second, either. For instance, I recall that one of the images we had was a diagram of the system catalog cross-references, and it was constantly out of date because of the difficulty of updating it. Admittedly, this was 15+ years ago. Maybe the state of the art in figure editors has advanced to the point where it won't be so hard. But color me suspicious. regards, tom lane
Re: Extra indentation in first line
"David G. Johnston" writes: > On Mon, Feb 26, 2018 at 6:43 AM, PG Doc comments form < > nore...@postgresql.org> wrote: >> Page: https://www.postgresql.org/docs/10/static/textsearch-features.html >> In some queries there is an extra indentation > I just now noticed the same thing while looking a report on GRANT syntax. > I've spotted checked a couple of other pages and found the same. The > "code" blocks housing examples sometimes has extra leading whitespace > (indentation). > We have recently switched to new tooling around the documentation so this > appearing now is not that surprising though I don't recall any recent > changes and this is the first report of such behavior I've seen. If you compare the different branches' versions of that page, it's OK in "devel", and OK in some very old branches like 9.2, but not OK in any of 9.3 through 10. So I'm thinking that somebody broke some version-specific website markup. No idea how to investigate further, but I'm cc'ing the www list for comment. regards, tom lane
Re: Images in the official documentation
On 27 February 2018 at 03:23, Tom Lane wrote: > Craig Ringer writes: > > On 26 February 2018 at 12:16, Tom Lane wrote: > >> How can we resolve these issues? > > > Question the assumptions and requirements. Why do we actually _need_ > > diffable, mergeable images? Sure, it'd be *nice*, but what's the real > world > > impact if we don't have it? > > Well, I'll tell you exactly why I'm being sticky about this: we've been > down this road before. We used to have some figures in .gif format, > and one of the problems with them was they were too hard to update. > I don't buy the "they won't need updates" argument for a second, either. > For instance, I recall that one of the images we had was a diagram of > the system catalog cross-references, and it was constantly out of date > because of the difficulty of updating it. > Yeah, that sounds painful. I can certainly see your objection when framed in terms of things like illustrations of catalogs and catalog relationships. If I were maintaining the docs in a vacuum, I'd use graphviz for something like that, because it's a figure that does need regular updates and changes. And because the list of fun things to do in my life definitely does not include hand-writing SVG. Not that tweaking GraphViz .dot is fun, but it's the default tool for a reason. I'd be awfully tempted to generate the node-map part of the catalog relationship .dot file from a query, too. I still advocate for relaxing the policy for images that are *not* likely to need frequent updates, but also for being conservative about how/when we include images. Does this add real value to the docs, is it worth any maintenance hassle? Then, for things that will change more, like catalogs, using a tool like graphviz. If we object to adding a docs build-dependency, we could always commit generated files like we already do for the 'configure' script, and make sure there's a committer/maintainer Make target that warns if the sources are newer than the docs. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: https://www.postgresql.org/download/linux/ubuntu/
> On 26 Feb 2018, at 16:18, Indrek K wrote: > Please upgrade PostgreSQL document to latest version > https://www.postgresql.org/download/linux/ubuntu/ > Change apt-get install postgresql-9.6 > postgresql-10 The download pages are not guaranteed to always be up to date with the current release version, hence the "substitute the version number as required” mentioned on the page. That being said, there is no reason not to update the page, it’s just not highly prioritized. I’m happy to do the legwork unless there are objections, cc:ing the -www list as it's a better place to discuss this. cheers ./daniel
