Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iytfh-0003iD-9s for pgsql-docs@arkaria.postgresql.org; Tue, 04 Feb 2020 08:35:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iytff-0005zm-Mj for pgsql-docs@arkaria.postgresql.org; Tue, 04 Feb 2020 08:34:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iytfe-0005ze-Vk for pgsql-docs@lists.postgresql.org; Tue, 04 Feb 2020 08:34:59 +0000 Received: from mail-lf1-x142.google.com ([2a00:1450:4864:20::142]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iytfX-0000bQ-5F for pgsql-docs@lists.postgresql.org; Tue, 04 Feb 2020 08:34:56 +0000 Received: by mail-lf1-x142.google.com with SMTP id r14so11598065lfm.5 for ; Tue, 04 Feb 2020 00:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zj3QgS7BEnQW2VbccFSTF2IYf1J7sw/f+jp7+avbS8g=; b=vfrCVEPTYRj7r06Gjm+LE+fqlJdty0oF6DRpoQo6gwoeDr/MAngmKlsNewE9fb+xvb 8kkT8xBeDrV8TPzR8elg0kFVMLLv495pZUZJmQtaFRMKJnUQEmOT6FHyMMx63Toyy0rB jS6I3MtoSL1cCjL8qY4AbtGixNZro5RY6oMHCTRp5dI+FbLzOrpYNGwqGhnV7Ot2hqZz OVK99G5Y0o7mv7usor3FKbGbLDBzk3YsCdlGYx9h7/RKitu9TJtwMAgubJsVfXZLtgMd SU3Dd9UV0pfJLXHfa9yuwUsO9rK8AxTzQ96GLoKeiWvMkbeTbsjLPViVlH9hcWIaFZU3 Wb0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zj3QgS7BEnQW2VbccFSTF2IYf1J7sw/f+jp7+avbS8g=; b=hg2XaRAQLvxWIY08Nm5Jfc463tmNv7b3U3Iiwrxg89EypJpI9MF6PlpJtI4cxLa8ec qsZE8NYOthYep2WG2J5Mcyo1RvwDvTDz6wD5vLbKpyisti2jQnoApwW1cFdrRjKfBlfg JPshh6LMDfL27DiwKCuGpiiTHwhz+jAnlp5Cxkx6+/Vq+aBeFaqn2cSqt/WcVJn3sd6R sz2cFpVaBFGiGqzI4NpM923RTTl6hq3x4XUBX0VbPAn+vqWLB5YGIV34fZHvPOIdDQzp i4TxiznHCoEjMluEPtViKiET49C9A/guVUQfbU+AuJFWkLjQ8kfR2qJnWCzEW5S7mNVa +D6g== X-Gm-Message-State: APjAAAUHAOjpMt2wyxaFTWKozffDJxCZ+N2VqAtlgUtVlCCQp7Vuqb6i 7IYLd7or3lmjilSTFuolM7sobcbc99XO5/sWf1ZHqg== X-Google-Smtp-Source: APXvYqw8qV7hW+J8Yx2ddFwILSWB3+RDy8dMk/iyTYrPw8dACuSOoGAh1vUwmsGF5y1b6MaKyEu1svFdC5MM/+7toWg= X-Received: by 2002:a19:550d:: with SMTP id n13mr14580087lfe.48.1580805289029; Tue, 04 Feb 2020 00:34:49 -0800 (PST) MIME-Version: 1.0 References: <157742545062.1149.11052653770497832538@wrigleys.postgresql.org> <20191227171654.GA2992@momjian.us> <8c2f4f1b90c993c8c6338b978a78a9ebbcd1c934.camel@cybertec.at> <20200114181331.GB10430@momjian.us> <20200114194502.GX3195@tamriel.snowman.net> <20200119035648.3k4d3erobborxwv3@rat.local> <957c35e3-8023-ebe6-3b51-3a620b66ae82@2ndquadrant.com> <20200124001208.6dessehrm7lgeqwz@rat.local> <20200203204244.GA15678@momjian.us> <3b1f6cb3-4a6c-fff7-59ae-b8ce0a9866d8@postgresql.org> In-Reply-To: <3b1f6cb3-4a6c-fff7-59ae-b8ce0a9866d8@postgresql.org> From: Magnus Hagander Date: Tue, 4 Feb 2020 09:34:37 +0100 Message-ID: Subject: Re: Documentation: 21.5. Default Roles To: "Jonathan S. Katz" Cc: Bruce Momjian , R Ransbottom , Ian Barwick , Stephen Frost , Laurenz Albe , Pg Docs Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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/