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 1jnNTl-0000Cg-Nz for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jun 2020 14:31:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNTk-0006Ut-Jk for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jun 2020 14:31:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jnNTk-0006Um-Cu for pgsql-hackers@lists.postgresql.org; Mon, 22 Jun 2020 14:31:20 +0000 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnNTh-0004Dk-QB for pgsql-hackers@postgresql.org; Mon, 22 Jun 2020 14:31:20 +0000 Received: by mail-ed1-x536.google.com with SMTP id k8so13817446edq.4 for ; Mon, 22 Jun 2020 07:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3Yxu/PwS/uhAu0LJ3hN3oUepX60l1/tvG6ixNEIWaJ4=; b=S04UZNv0Efjy4wHM3l14o0dAKw0F8Q/7bmqTHJAmUM6w53sCKcA7T1Spgk8IiaYzZz lGmke90l1XXH+MPGHAcu1mB4msJ1cAyFN7qQMjoGPl9F0PtNxNCk3u/+e9HQq1CVkO3n xo92Rc1Gnt77li+8+Ad+gLmyxM3tr2v6yOzjcDG7xrTm9ns/xqbjytbKPbWEB7EPEvNJ 2iVZOJrqYitB8rYTDkt7SWmN0NxyTQlgIv0HN7vR9pqx+F8SJesNYtGKzdruPk525fU6 BhR18jMzFEr4qZmsM+KmNJR1+rQoKOby4rlnMavmqn6JJAevMItvXFTKM8ZZLtzSowA+ eLDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3Yxu/PwS/uhAu0LJ3hN3oUepX60l1/tvG6ixNEIWaJ4=; b=AcvMCj9dh+NPq9zZHRJwBSXhSop8fAb697QZRQ0E69B/AqYRLpjy8irmaiPy7uLD6N AE3KoBLZ3DhRDeFUs8xKB4V010TupYsordjS/jaoAuQMRblTLat2Hlqm73dOym/IPPRL 56QGCh0flf4z/HI7TY02Lz/C/zOPhLDI30uun8BMmm+3+wrwH2eahVc75dyjvOJvykTS h9o2kS6PBPkeW9yIoUy1noucrVviHiDuJquBIkXqrUlnyhfscY1PR3zidGdevgTwdSRD 4j4oe699a/mxEEWS76OAYFsdvhYzYwDhzXM3etewCvz39p8u9/5jO7p6txsDld0wi3xf 3Hkw== X-Gm-Message-State: AOAM533TagNQ1lkEZFzbV0nNx2pUuOS/nuwQg2byCF9J6Mvamszw19Zz I+GM74jNWnt420ODxlug1HyhcA== X-Google-Smtp-Source: ABdhPJyvLCm19oQgyQecGYZshkMBxh3VkNZJzzNZBKG90EiyzpO/vaeroahKxEpYYrNehllNa+YTDA== X-Received: by 2002:a50:f297:: with SMTP id f23mr16928263edm.222.1592836276669; Mon, 22 Jun 2020 07:31:16 -0700 (PDT) Received: from localhost (ip-86-49-253-141.net.upcbroadband.cz. [86.49.253.141]) by smtp.gmail.com with ESMTPSA id p13sm12544417edq.50.2020.06.22.07.31.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jun 2020 07:31:15 -0700 (PDT) Date: Mon, 22 Jun 2020 16:31:14 +0200 From: Tomas Vondra To: Robert Haas Cc: Julien Rouhaud , Peter Eisentraut , pgsql-hackers Subject: Re: suggest to rename enable_incrementalsort Message-ID: <20200622143114.suqf2korqpydbxxf@development> References: <20200621112159.qtgedtrqw2c47pm4@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Jun 22, 2020 at 10:16:54AM -0400, Robert Haas wrote: >On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra > wrote: >> The reason why I kept the single-word variant is consistency with other >> GUCs that affect planning, like enable_indexscan, enable_hashjoin and >> many others. > >Right, so that makes sense, but from a larger point of view, how much >sense does it actually make? I mean, I get the argument from tradition >and from internal naming consistency, but from a user perspective, why >does it makes sense for there to be underscores between some of the >words and not others? I think it just feels random, like someone is >charging us $1 per underscore so we're economizing. > Sure. I'm not particularly attached to the current GUC, I've only tried to explain that the naming was not entirely random. I agree having an extra _ in the name would make it more readable. >So I'm +1 for changing this, and I'd definitely be +1 for renaming the >others if they weren't released already, and at least +0.5 for it >anyhow. It's bad enough that our source code has names_like_this and >NamesLikeThis and namesLikeThis; when we also start adding >names_likethis and NamesLike_this and maybe NaMeS___LiKeTh_is, I kind >of lose my mind. And avoiding that sort of thing in user-facing stuff >seems even more important. > OK, challenge accepted. $100 to the first person who commits a patch with a variable NaMeS___LiKeTh_is. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services