Re: Documentation: 21.5. Default Roles
On Mon, Feb 3, 2020 at 9:59 PM Jonathan S. Katz wrote: > > On 2/3/20 3:42 PM, Bruce Momjian wrote: > > On Thu, Jan 23, 2020 at 07:12:08PM -0500, R Ransbottom wrote: > >> On Mon, Jan 20, 2020 at 12:23:48PM +0900, Ian Barwick wrote: > >>> On 2020/01/19 12:56, R Ransbottom wrote: > >> > I would hope to find correct documentation somewhere--that somewhere > >> > >>> Indeed, however it's important that the PostgreSQL documentation remains > >>> stable for released versions. > >> > >>> As-is, the current patch set would result in the term "default role(s)" > >>> disappearing from the documentation in the next minor release, which is > >>> bound to cause confusion for anyone searching the documentation for the > >>> term they're familiar with (unless they happen to be reading this thread > >>> or following the git commit log). Cue cries of "OMG Postgres removed a > >>> feature in a minor release!!!?!!". > >> > >>> And as Stephen mentions, it will break a lot of secondary documentation - > >>> not just blogs but things like internal training materials etc. > >> > >>> If this change is made (which I'm personally not against), then it should > >>> be > >>> only from PostgreSQL 13. For 9.6 ~ 12, IMHO it would be better to tweak > >>> the > >>> existing documentation to somehow mention that "default roles" should be > >>> thought of as "prefined roles", and note they will be called this from > >>> Pg13. > >> > >> Ian, agreed modulo 13. > >> > >> The current section(s) could forward readers to a revised section. The > >> DEFAULT_ROLE_* stuff could carry two names to allow a comprehensive fix > >> in 12.X. That could allow the deprecation and misinformation to end one > >> EoL sooner. > > > > With minor releases coming next week, and no movement on doing web > > redirects, and no clarity on what this is missing even in master, I will > > revert this patch in all branches soon. I think everyone agrees the new > > documentation title is better, but we don't want to break things or add > > inconsistency to do it. > > Sorry, I missed the original comment on the "web redirects" Same here. It was buried a little too deep in an existing therad. > > So, if there was something done to redirect people from specific > deprecated documentation pages historically, it was before my time. Most > of the redirects have been as general purposes ones (e.g. /docs/12), the > rules we put in for getting rid of "static", and the release notes, > which still receives some negative feedback towards it for different > reasons (though I think overall the effort was well-received). Anyway, > if we had a redirect in place, I'd want us to do it well. We have something close to it in commit 496416ceda9c1015d9e7a6ef4b4fb18dae8a8d4e. But that doesn't actually generate redirects when requests are coming in from the outside -- it just makes sure our *internal* links can survive the rename of a file between branches. So it may not be exactly what's being looked for here, but it might be a starting point. Probably the same underlying mapping table could be used, but I haven't investigated that closely enough to say if it's doable at this point, just that it's a starting point. Using this feature to handle the rename of a file *between* major versions, thus leaving the changes in master, should be safe (as long as we add an entry to that table in pgweb). As for back branches, I think we have to say that it's too close to the minor release to safely have something done in pgweb before then. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Move description of general lock behaviour out of the "13.3.1. Table-level Locks section"
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.4/explicit-locking.html Description: Hi The "13.3.1. Table-level Locks" subsection mentions the following: "Once acquired, a lock is normally held till end of transaction." (maybe we should also squeeze a "...till the end of a transaction" in there) According to a helpful stranger on IRC, this behaviour is also true for row-level locks. Since this sentence also applies to the row-level locks described in the following subsection 13.3.2 I think it would be more fitting to move the paragraph containing this sentence to the introduction of the topic in section "13.3. Explicit Locking". This would then read something like: --- 13.3. Explicit Locking PostgreSQL provides various lock modes to control concurrent access to data in tables. These modes can be used for application-controlled locking in situations where MVCC does not give the desired behavior. Also, most PostgreSQL commands automatically acquire locks of appropriate modes to ensure that referenced tables are not dropped or modified in incompatible ways while the command executes. (For example, TRUNCATE cannot safely be executed concurrently with other operations on the same table, so it obtains an exclusive lock on the table to enforce that.) Such explicit locks are normally held till the end of a transaction. But if a lock is acquired after establishing a savepoint, the lock is released immediately if the savepoint is rolled back to. This is consistent with the principle that ROLLBACK cancels all effects of the commands since the savepoint. The same holds for locks acquired within a PL/pgSQL exception block: an error escape from the block releases locks acquired within it. To examine a list of the currently outstanding locks in a database server, use the pg_locks system view. For more information on monitoring the status of the lock manager subsystem, refer to Chapter 28. --- What do you think? Cheers, Silvan
btree index maximum row size
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/limits.html Description: Appendix K (PostgreSQL Limits) - doesn't mention the (btree) index row size limits. I think that it should.
documentation extension request - order with function over aggregated functions
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.5/queries-order.html Description: In https://www.postgresql.org/docs/9.5/queries-order.html it is said that the following is intentionally not allowed: ``` SELECT a + b AS sum, c FROM table1 ORDER BY sum + c; -- wrong ``` It took me a while to figure out how to do it properly so I propose to add the following (or similar) info: --- If you need to sort by this kind of expression, you will have to retrieve an extra column with the required computation and use it as a sorting key: ``` SELECT a + b AS sum, c FROM table1, a + b + c AS my sorting_key ORDER BY my_sorting_key; -- correct ```
Re: Documentation: 21.5. Default Roles
Greetings, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > On 2020-Feb-03, Jonathan S. Katz wrote: > > > So, if there was something done to redirect people from specific > > deprecated documentation pages historically, it was before my time. Most > > of the redirects have been as general purposes ones (e.g. /docs/12), the > > rules we put in for getting rid of "static", and the release notes, > > which still receives some negative feedback towards it for different > > reasons (though I think overall the effort was well-received). Anyway, > > if we had a redirect in place, I'd want us to do it well. > > I +1 changing the title and +1 having the redirect. That said, I think > people landing in a page titled "predefined roles" when they're looking > for a page titled "default roles" would be quite confused for a while > and perhaps continue to search for the page they think they're looking > for. (I know, it has happened to me.) I suggest we add a very short > paragraph --maybe a -- to the effect that feature-X used to be > called feature-Y, immediately following the section title. I'm a bit confused as it sounded like having the redirect wouldn't be easy to do.. I also agree that keeping the URL the same as today but changing that URL to be talking about 'predefined roles' would be quite confusing. Having some kind of landing page with the existing URL that had a link for people to click on to get to the new URL seems like it would possibly work. I'd be happier with having that done in master and keeping the back-branches as-is, since I don't really like the idea that we're retroactively renaming a feature in our existing releases. That said, if we at least have the landing page then at least people will be less likely to be confused. Thanks, Stephen signature.asc Description: PGP signature
Re: Documentation: 21.5. Default Roles
On 2/4/20 3:34 AM, Magnus Hagander wrote: > On Mon, Feb 3, 2020 at 9:59 PM Jonathan S. Katz wrote: >> So, if there was something done to redirect people from specific >> deprecated documentation pages historically, it was before my time. Most >> of the redirects have been as general purposes ones (e.g. /docs/12), the >> rules we put in for getting rid of "static", and the release notes, >> which still receives some negative feedback towards it for different >> reasons (though I think overall the effort was well-received). Anyway, >> if we had a redirect in place, I'd want us to do it well. > > We have something close to it in commit > 496416ceda9c1015d9e7a6ef4b4fb18dae8a8d4e. But that doesn't actually > generate redirects when requests are coming in from the outside -- it > just makes sure our *internal* links can survive the rename of a file > between branches. Ah cool, didn't realize we had this feature :) > So it may not be exactly what's being looked for here, but it might be > a starting point. Probably the same underlying mapping table could be > used, but I haven't investigated that closely enough to say if it's > doable at this point, just that it's a starting point. Yeah. It could be as simple as having a flag on it to say it should redirect if the old file (presumably "file2" in the model) is hit. I'm saying this without diving into the mechanics of the code. > Using this feature to handle the rename of a file *between* major > versions, thus leaving the changes in master, should be safe (as long > as we add an entry to that table in pgweb). > > As for back branches, I think we have to say that it's too close to > the minor release to safely have something done in pgweb before then. This part I agree on, but let's sync offline to see if there is something within reason, with a preference to *not* rush if we're worried about breaking something right before release. Jonathan signature.asc Description: OpenPGP digital signature
Re: documentation extension request - order with function over aggregated functions
On Tue, 2020-02-04 at 08:59 +, PG Doc comments form wrote: > SELECT a + b AS sum, c FROM table1 ORDER BY sum + c; -- wrong > > It took me a while to figure out how to do it properly so I propose to add > the following (or similar) info: > > --- > If you need to sort by this kind of expression, you will have to retrieve an > extra column with the required computation and use it as a sorting key: > > > SELECT a + b AS sum, c FROM table1, a + b + c AS my sorting_key ORDER BY > my_sorting_key; -- correct Not quite correct, because you get an extra unnecessary output column. You can either not use an alias in ORDER BY: SELECT a + b AS sum, c FROM table1 ORDER BY a + b + c; or you can use a subquery: SELECT sum, c FROM (SELECT a + b AS sum, c FROM table1) AS subq ORDER BY sum + c; Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
