Re: Proposal: adding a better description in psql command about large objects - Mailing list pgsql-hackers

From Guillaume Lelarge
Subject Re: Proposal: adding a better description in psql command about large objects
Date
Msg-id CAECtzeUJK4rZnnuxcjCSM2rCn=16yifBExguaYaWgqbN=yqpHw@mail.gmail.com
Whole thread Raw
In response to Proposal: adding a better description in psql command about large objects  ("Thibaud W." <thibaud.walkowiak@dalibo.com>)
List pgsql-hackers
Le ven. 3 juin 2022 à 19:29, Nathan Bossart <nathandbossart@gmail.com> a écrit :
On Fri, Jun 03, 2022 at 12:56:20PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> 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.


Sounds good to me too.

Thanks.


--
Guillaume.

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: should check interrupts in BuildRelationExtStatistics ?
Next
From: Michael Paquier
Date:
Subject: Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch