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 1heMR4-0008Ca-6h for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Jun 2019 16:30:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1heMR3-0000NX-33 for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Jun 2019 16:30:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1heMR2-0000NQ-Qo for pgsql-hackers@lists.postgresql.org; Fri, 21 Jun 2019 16:30:44 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1heMR0-0003fK-Ej for pgsql-hackers@postgresql.org; Fri, 21 Jun 2019 16:30:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x5LGUc3C020373; Fri, 21 Jun 2019 12:30:38 -0400 From: Tom Lane To: Robert Haas cc: Ian Barwick , Stephen Frost , Amit Kapila , "pgsql-hackers@postgresql.org" Subject: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions In-reply-to: References: <20190614160835.GF2480@tamriel.snowman.net> <20190616171610.GO2480@tamriel.snowman.net> <27dc9f8d-8d8f-9dd1-0494-5d8bd2f49a45@2ndquadrant.com> Comments: In-reply-to Robert Haas message dated "Fri, 21 Jun 2019 10:45:02 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20371.1561134638.1@sss.pgh.pa.us> Date: Fri, 21 Jun 2019 12:30:38 -0400 Message-ID: <20372.1561134638@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > To me, forcing every tools author to use postgresql.conf parsing tools > rather than just appending to the file is a needless burden on tool > authors. I'd vote for just having ALTER SYSTEM silently drop all but > the last of duplicated entries. I haven't been paying too close attention to this thread, but isn't that exactly what it does now and always has? guc.c, at least, certainly is going to interpret duplicate entries that way. regards, tom lane