From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_createsubscriber TAP test wrapping makes command options hard to read. |
Date: | 2024-12-12 03:13:40 |
Message-ID: | CAHut+PvFGytgJT+K_e2x+uWKuVYCBR3HNaNtPKYEkO3YxAwZvw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 12, 2024 at 1:46 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Peter Smith <smithpb2250(at)gmail(dot)com> writes:
> > The strange thing is there are other commands in that file very
> > similar to the ones I had changed but those already looked good, yet
> > they remained unaffected by the pgperltidy. Why?
>
> You sure it's not just luck-of-the-draw? I think that perltidy
> is just splitting the lines based on length, so sometimes related
> options would be kept together and sometimes not.
>
TBH, I have no idea what logic perltidy uses. I did find some
configurations here [1] (are those what it pgperltidy uses?) but those
claim max line length is 78 which I didn;t come anywhere near
exceeding.
After some more experimentation, I've noticed that it is trying to
keep only 2 items on each line. So whether it looks good or not seems
to depend if there is an even or odd number of options without
arguments up-front. Maybe those perltidy "tightness" switches?
So, AFAICT I can workaround the perltidy wrapping just by putting all
the noarg options at the bottom of the command, then all the
option/optarg pairs (ie 2s) will stay together. I can post another
patch to do it this way unless you think it is too hacky.
======
[1] https://github.com/postgres/postgres/blob/master/src/tools/pgindent/perltidyrc
Kind Regards,
Peter Smith.
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Harris | 2024-12-12 03:14:20 | Re: FileFallocate misbehaving on XFS |
Previous Message | David Rowley | 2024-12-12 03:09:44 | Re: Remove useless GROUP BY columns considering unique index |