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 1nxB6z-0000XN-0I for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jun 2022 17:29:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nxB6x-0008Lt-SU for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jun 2022 17:29:23 +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 1nxB6x-0008Lk-H9 for pgsql-hackers@lists.postgresql.org; Fri, 03 Jun 2022 17:29:23 +0000 Received: from mail-il1-x12c.google.com ([2607:f8b0:4864:20::12c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nxB6p-0005TI-RA for pgsql-hackers@lists.postgresql.org; Fri, 03 Jun 2022 17:29:22 +0000 Received: by mail-il1-x12c.google.com with SMTP id b17so3370665ilh.6 for ; Fri, 03 Jun 2022 10:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ZNFGGI/BexhBUdfcbQPb7pTeVP0veRjyDzZzl0Xy7ok=; b=hgRynbhKx3LRPCvbRqKl5W8PaylUq7qOOb8d3Qoua6AXERr0nTAK1yzMpxokYk+QBW ETZNUt1N5bl0LElahuxtIwOsUpkSI8vUkpRfXTZyuiJAAvgHss4WC9ZwPft7v5Hdc5Pw ufbBPr1HIAwLCflDIsLeauNG9TBieY8NeRMgjF0p0nAPugyMqS1b1BS2NJ+Y3YcLAJ+Q lGJXWiKFy9GOWk591qWkAw+Kj9fFIhDlgLC4mfOUV2QLSmqy7vcBHxc0HwCA5Fn2tcQd Kwksz+dKuhHmWEiOaopSa2MhXkN5Z6Q70K0wdRSNoE024QUavqYeBGtt3HG0zumz9XvF 4OyQ== 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; bh=ZNFGGI/BexhBUdfcbQPb7pTeVP0veRjyDzZzl0Xy7ok=; b=lSfsQWqYuGda/R4kPnjFnbr9nRBJABsQPzATOejRYO+4Yf5xbq1YNALQKa0oylrJkT /2A2zZCvaRkru9hzB5Rw/E7Nx9g0Ze2NSObcJUGDTe/KW5q04O2bhiWs5RLmxLJ3TUeC /0+iRztUuGOlub2JlgFuOkrwat7Z/NWmYdxUAtMxNnThHEZ/rdqe7lKPiv7CBc3A1vDF f3xE4uWawnMDt65fBT34OQhEHTulYCChbJkbIlLmjQLEeHWUKdExUjLXjgiZZxtPBpNZ mj9wbIGDRlsB4KSEly/IUHaJr4hN2bRwGscKs7242tu3/GMfOU7ohWXRqUPxzcB5FMm9 FrsQ== X-Gm-Message-State: AOAM5333MmK80VOS1XzJg1gnP/E4hQcxcEe6RNssLtu2d5FwYEsFdtPU z2DjpaePHLTVFh4qYIHuOFE= X-Google-Smtp-Source: ABdhPJzpe0xFw6EahSog8ONsjuQkByLh0TXakwKw8wQwyZ44QjFbkxvHip9vwXKQIBXKkbR8EB8gng== X-Received: by 2002:a05:6638:35a1:b0:330:a6c5:bf97 with SMTP id v33-20020a05663835a100b00330a6c5bf97mr6784296jal.250.1654277354140; Fri, 03 Jun 2022 10:29:14 -0700 (PDT) Received: from nathanxps13 ([2600:1700:48f8:340f:ed23:4662:3872:4137]) by smtp.gmail.com with ESMTPSA id q24-20020a027b18000000b003313005be01sm2747625jac.141.2022.06.03.10.29.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jun 2022 10:29:13 -0700 (PDT) Date: Fri, 3 Jun 2022 10:29:11 -0700 From: Nathan Bossart To: Tom Lane Cc: "Thibaud W." , pgsql-hackers@lists.postgresql.org Subject: Re: Proposal: adding a better description in psql command about large objects Message-ID: <20220603172911.GA2671189@nathanxps13> References: <43f0439c-df3e-a045-ac99-af33523cc2d4@dalibo.com> <20220602214625.GA2494933@nathanxps13> <2e872233-1642-439c-dd94-56fc25d398cb@dalibo.com> <20220603143921.GA2624579@nathanxps13> <216601.1654269131@sss.pgh.pa.us> <20220603152319.GA2627191@nathanxps13> <272177.1654275380@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <272177.1654275380@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jun 03, 2022 at 12:56:20PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> Another option could be to move it after the "Input/Output" section so that >> it's closer to some other commands that involve files. I can't say I have >> a strong opinion about whether/where to move it, though. > > Yeah, I thought of that choice too, but it ends up placing the > Large Objects section higher up the list than seems warranted on > frequency-of-use grounds. Fair point. > After looking at the output I concluded that we'd be better off to > stick with the normal indentation amount, and break the lo_import > entry into two lines to make that work. One reason for this is > that some translators might've already settled on a different > indentation amount in order to cope with translated parameter names, > and deviating from the normal here will just complicate their lives. > So that leaves me proposing v5. I see. As you noted earlier, moving the entries higher makes the inconsistent indentation less appealing, too. So this LGTM. > (I also fixed the out-of-date line count in helpVariables.) Yeah, it looks like 7844c99 missed this. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com