Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nCZEc-0002xh-5Q for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Jan 2022 03:44:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nCZEa-0006n0-Gv for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Jan 2022 03:44:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nCZEa-0006mr-55 for pgsql-hackers@lists.postgresql.org; Wed, 26 Jan 2022 03:44:36 +0000 Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nCZET-00089s-4S for pgsql-hackers@lists.postgresql.org; Wed, 26 Jan 2022 03:44:34 +0000 Received: by mail-io1-xd34.google.com with SMTP id h7so8268451iof.3 for ; Tue, 25 Jan 2022 19:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=lqZTcGcFt1o7FrXrGGxTnRg1Zr0M2xREBrJi1tK2ag8=; b=wfzQsExKu/j1rHdqEFq7ti9/HAi/fLygNHQxndZX2Rv0dzAnKe7z3TQFrSN7mlurdb xahCe9aAq10BCsNEA2rkqZBtm3SjcAmRCPdnaAb/tZPy18fW9BNUCe0TPrIoR6j1G65W qP1R+xF5gtWFxZFVpFZ8Vjzi5XzkywQyfQNsgnzRGpJ/R/AilqMcX/ZxvSJf+y5bZUWu ldQZR5rnu/tUAhBPzUk/5uaEH170I3y2XWgkjyYOrKd3xXRJBMunQUTrBz7DiKjTW4IV ibm0Kn+CcmlT7s61BQPt5NES1spK6dk9wtSxNqBtidK8IgBR8HSywtxwPRnbaToZ/QqZ lymQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lqZTcGcFt1o7FrXrGGxTnRg1Zr0M2xREBrJi1tK2ag8=; b=nUdWI2Omg+BRO86Jn4g/IHfZqKSAlIRol/PggozlUGZIgMvl2/JdfFRPPmnS6yh+05 F+x36NNGUoUHh4f2bPvDm48z8L3W5ya6uvEUPnlVcgoIIzGK4GcD2+RXWhUjo8ZUyoZe pdwWLrnH7JSKZ9uvUlrOdXTmmg5vG6515PwYAyhUYc5rbK8Rdq36v1bfWKH7GAUawAQt WdtCZEBpugBBgd9CWr5Y/hR7gR7/GD9S70zMIKhTxT8JW7L6W/6JTecFz/Yse0B1FYjo OwvQfoeHAcVQMHdxJYiFTB6srzYjk8kG9Griqy0Y4/Wb5inDiiWfMRftwNehw44paLf6 lgSg== X-Gm-Message-State: AOAM530VB6qjJlNyLPNna5VoeQz0qdbV0Ls+jY5oCbeDUqV5ZDH/BZgs Z3ViOnnqFCnZvdRcQ2B3CzGR9A== X-Google-Smtp-Source: ABdhPJwgB80r1MzBZSLq/Trpthlk9mkKKXz48moOOhwfxWL8aXTgANtoZHjzeSNSluvHTRYkfQ2IEA== X-Received: by 2002:a02:a319:: with SMTP id q25mr7433565jai.276.1643168668287; Tue, 25 Jan 2022 19:44:28 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id y6sm10767563ill.17.2022.01.25.19.44.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jan 2022 19:44:27 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 96A45801021; Tue, 25 Jan 2022 21:44:26 -0600 (CST) Date: Tue, 25 Jan 2022 21:44:26 -0600 From: Justin Pryzby To: Michael Paquier Cc: Peter Eisentraut , Kyotaro Horiguchi , pgsql-hackers@lists.postgresql.org, bruce@momjian.us, tgl@sss.pgh.pa.us Subject: Re: GUC flags Message-ID: <20220126034426.GN23027@telsasoft.com> References: <20220105.114757.369416916044334409.horikyota.ntt@gmail.com> <20220105030648.GE14051@telsasoft.com> <20220105235517.GR14051@telsasoft.com> <20220106053641.GW14051@telsasoft.com> <20220125010729.GC23027@telsasoft.com> <20220125180751.GH23027@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jan 26, 2022 at 09:54:43AM +0900, Michael Paquier wrote: > On Tue, Jan 25, 2022 at 12:07:51PM -0600, Justin Pryzby wrote: > > On Tue, Jan 25, 2022 at 11:47:14AM +0100, Peter Eisentraut wrote: > >> Does this stuff have any value for users? I'm worried we are exposing a > >> bunch of stuff that is really just for internal purposes. Like, what value > >> does showing "not_in_sample" have? On the other hand, "guc_explain" might > >> be genuinely useful, since that is part of a user-facing feature. (I don't > >> like the "guc_*" naming though.) > > EXPLAIN is useful to know which parameter could be part of an explain > query, as that's not an information provided now, even if the category > provides a hint. COMPUTED is also useful for the purpose of postgres > -C in my opinion. It seems like an arbitrary and short-sighted policy to expose a handful of flags in the view for the purpose of retiring ./check_guc, but not expose other flags, because we thought we knew that no user could ever want them. We should either expose all the flags, or should put them into an undocumented function. Otherwise, how would we document the flags argument ? "Shows some of the flags" ? An undocumented function avoids this issue. Should I update the patch to put the function back ? Should I also make the function expose all of the flags ? -- Justin