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 1nx995-0002dv-SC for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jun 2022 15:23:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nx993-0005g6-RK for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jun 2022 15:23:25 +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 1nx993-0005eF-FK for pgsql-hackers@lists.postgresql.org; Fri, 03 Jun 2022 15:23:25 +0000 Received: from mail-il1-x12c.google.com ([2607:f8b0:4864:20::12c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nx990-0000Nz-LW for pgsql-hackers@lists.postgresql.org; Fri, 03 Jun 2022 15:23:24 +0000 Received: by mail-il1-x12c.google.com with SMTP id u2so6154344iln.2 for ; Fri, 03 Jun 2022 08:23:22 -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=5MFry9Q+X2+y5Fu+7KKMd1m8FRcngYGmmjGeHAFCuA0=; b=kMlNLVnZOCUmu13gjv1/74fBOVyizBah7Lp5suMVVhHyIcDmMcGldMbpbMz3HUmAwo mWl/QE1Iu23/QkCocSqGxh020pBegx6NvAK2beAlGN87SIhCRiIGn9EMXxOvFICW23nj F5adPzydcrhQNdB8L1BKxa+i0ZbsK9vt6hHF1HTc4y7EnOjjzDLLaS2P7TNXcU6Dk+27 SAHgGopnD9NNyrh8A6W1kKQWgFs/S9Hix66VFvBiFLHsmHE8ew50IYWSyCtin2rrO8BI MVuLBUZYtPJn5c24dqIGt3sez2Hfu4gKdMqSBvWzzSDB43DCnjPGWNqGFdM0K2S3eYoF yHlQ== 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=5MFry9Q+X2+y5Fu+7KKMd1m8FRcngYGmmjGeHAFCuA0=; b=RNpYBo2oqPU3H3vvJN/e39MZksr6t9Vb+gYyQ5fxMuGvTYtqwGww0nzplmSem56ESG YUsjb04egVqB52azikBemIjYICx6Swi5pptc7lenju6Ixm9JzwAGK1f4LtE00Y4qUtFX 4qLEr6NgSpW3U9Ya6txZSc2mMmq807OeUhnlCBR2ScDRHa9GXJVuZHZtAR62MPVXyWG2 WvJDrmBShZJqiF9+teK88th8WbpvH7ffNPiWWNRZNCzGi1qIGXkzQmuTxLS+xX9SRf8C d8GUOfwod98Gry+PXKSZsM/GYeJWchYbTKp35f8BuGEdW/90YBmNOiVRpru+Vq6FLk4+ XrNA== X-Gm-Message-State: AOAM532/2wKCDRKXpZ/VoMVNZafBDrET4DlmQPtpnaQeRhe0KdStyF7H wtOM+Ufa3aqU/ZnG8+Pjy0vdTfOQTuM= X-Google-Smtp-Source: ABdhPJzYm494IkUv6fgH/0Cju8ChflDkPsf1AoDjaJBKbWyF8EveGU7n3ecv8VhR2IOm3TmkgQD4Jw== X-Received: by 2002:a05:6638:41a4:b0:330:b6ad:e0b5 with SMTP id az36-20020a05663841a400b00330b6ade0b5mr6064530jab.101.1654269801946; Fri, 03 Jun 2022 08:23:21 -0700 (PDT) Received: from nathanxps13 ([2600:1700:48f8:340f:4836:c62e:1c51:862d]) by smtp.gmail.com with ESMTPSA id g18-20020a926b12000000b002d3b5a2bb7dsm2878395ilc.4.2022.06.03.08.23.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jun 2022 08:23:21 -0700 (PDT) Date: Fri, 3 Jun 2022 08:23:19 -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: <20220603152319.GA2627191@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <216601.1654269131@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 11:12:11AM -0400, Tom Lane wrote: > * How about "write large object to file" and "read large object from > file"? As it stands, if you are not totally sure which direction is > export and which is import, this description teaches you little. +1 > * While we're here, it seems like this whole group was placed at the > end because of add-it-to-the-end-itis, not because that was the > most logical place for it. The other commands that interact with > the server are mostly further up. My first thought is to move it > to just after the "Informational" group, but I'm not especially > set on that. Making it not-last might make it harder to get away > with the inconsistent indentation, though. 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. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com