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 1iDavj-0002gZ-4n for pgsql-docs@arkaria.postgresql.org; Thu, 26 Sep 2019 21:04:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iDavh-0003Tc-P5 for pgsql-docs@arkaria.postgresql.org; Thu, 26 Sep 2019 21:04:01 +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 1iDavh-0003TV-CX for pgsql-docs@lists.postgresql.org; Thu, 26 Sep 2019 21:04:01 +0000 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iDave-0002aQ-Ep for pgsql-docs@postgresql.org; Thu, 26 Sep 2019 21:04:01 +0000 Received: by mail-wm1-x343.google.com with SMTP id y21so4014261wmi.0 for ; Thu, 26 Sep 2019 14:03:58 -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:user-agent; bh=vaqAUorg2W2syMTtOCJ0lTa99HojPgJ/NqOOR3XnpzU=; b=e44wMziLpeeBLyd1I10Th11XogskrPmg/kXVv37ubX/JOmKP/UiW/9xo6VnIzqTM9q kdMkwulWWVovF/qFjPx5Cazm3HhvmPN3zM6h3lKd+wxbzqvDh4l7nZFpi9eFRfBG/7TR X3X8/d4yRA/dD1Qyy4ClXa7cCA1EO4bVrEA/2S98/LG8L/lYnTf5mbKkJoAJvbjq3BE1 B37yhKMiAFjI/h5nTDbp1PMMOgcBsIJ4UHtEimvZilyUZbcJBOVDOeIidgj6TEa+o46U y/jNLetEv+cLZJYYILopYEx7IBEiyO1AZCRD4pw4l48n9A8PsWDGhBpypD7FL1/VqnMq YU+g== 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:user-agent; bh=vaqAUorg2W2syMTtOCJ0lTa99HojPgJ/NqOOR3XnpzU=; b=qBYB8jxK6ZDRlGgWBpBcWXHbr3brNyOVw3U/su4YYcXn1VM2gk1TcFI8+ZPROy1V9g A372AEIgS1bxNbfBPsLCnSO6mXnf61RK05+FZWJilwf+0ImtUDuYfpK9V/msYoOsgDrN f3OWV6Apz3gEr1iW38nOUCE22XTA/6qCm2V/44iCznlGafn8j65MW8pDfMQG9Oa5nfxv rXN/cHvLo+Y38Uw19TEGpby9DqXWMvtgYTooJ6/s8/YC3Wm5C1gBAdiLxqhjj2iyjrhe U6bjkDu/3cw2DGzBqTyiXo0u/UlwdnRstGQYLHk8xdP9ywcKMJhbtbdOftkCDTROLYFU XMsA== X-Gm-Message-State: APjAAAUhA0jFDiqZamOyjSkZzVRNwUjx83/2OkZDd8yFyEhL3sU0swdp g98wonhOClUZnG15HPvVg/qjTZgrnsw= X-Google-Smtp-Source: APXvYqyaEUYEjVaW9WsCrtWCDRDtSpiCdRxgo23RQFhNniJtYFwGCsNeGnOV3Ijf2c/lpkb1N1sS1g== X-Received: by 2002:a05:600c:230d:: with SMTP id 13mr4792617wmo.114.1569531836337; Thu, 26 Sep 2019 14:03:56 -0700 (PDT) Received: from localhost (ip-86-49-253-183.net.upcbroadband.cz. [86.49.253.183]) by smtp.gmail.com with ESMTPSA id r13sm814308wrn.0.2019.09.26.14.03.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2019 14:03:55 -0700 (PDT) Date: Thu, 26 Sep 2019 23:03:54 +0200 From: Tomas Vondra To: Bruce Momjian Cc: Alvaro Herrera , PostgreSQL-documentation Subject: Re: Most-common value docs in PG 12 Message-ID: <20190926210354.dcwq5frjs44gbvkz@development> References: <20190926200522.GB16366@momjian.us> <20190926201755.GA18930@alvherre.pgsql> <20190926202059.GD16366@momjian.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20190926202059.GD16366@momjian.us> User-Agent: NeoMutt/20180716 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Sep 26, 2019 at 04:20:59PM -0400, Bruce Momjian wrote: >On Thu, Sep 26, 2019 at 05:17:55PM -0300, Alvaro Herrera wrote: >> On 2019-Sep-26, Bruce Momjian wrote: >> >> > On Wed, Sep 11, 2019 at 06:15:22PM -0300, Alvaro Herrera wrote: >> > > On 2019-Aug-30, Bruce Momjian wrote: >> > > >> > > > OK, how is this patch? I didn't mention psql since I think everyone >> > > > expects psql to show all information about tables and indexes. >> > > >> > > Why would you change perform.sgml? It seems unnecessary; the commands >> > > shown work fine. >> > >> > I realize they work fine, but the ordering in the examples not matching >> > the defined order suggests that ordering matters, but it does not. >> >> Well, I mean exactly the other way around: the fact that the orders >> don't match illustrates that the order is not important. And that is >> reinforced by the explanation indicating explicitly that it does not >> matter: > >Uh, people normally list things in defined order, so you would usually >not list them in non-defined order unless there is a purpose. Doing >that just to illustrate the order doesn't matter seems odd. > Well, that assumes there is a definition, and I don't think the zipcodes table is defined anywhere. So how do you know in what order are those columns defined? Now, maybe the table should be defined somewhere in perform.sgml - I don't recall why exactly I chose not to do that, maybe because there is no universal definition (one country uses text, another number, ...). I do however agree that had there been such definition, it's probably natural to list columns in the same order. We know the order is not important, the proposed patch states that explicitly, but this just feels natural. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services