On 2023-08-12 Sa 11:57, Andrew Dunstan wrote:
On 2023-08-11 Fr 19:17, Tom Lane wrote:
Peter Geoghegan writes:
I'm starting to have doubts about this policy. There have now been
quite a few follow-up "fixes" to indentation issues that koel
complained about. None of these fixups have been in
Andrew Dunstan writes:
> Based on recent experience, where a lot koel's recent complaints seem to
> be about comments, I'd like to suggest a modest adjustment.
> First, we should provide a mode of pgindent that doesn't reflow
> comments. pg_bsd_indent has a flag for this (-nfcb), so this should
On 2023-10-28 Sa 12:09, Tom Lane wrote:
Andrew Dunstan writes:
Based on recent experience, where a lot koel's recent complaints seem to
be about comments, I'd like to suggest a modest adjustment.
First, we should provide a mode of pgindent that doesn't reflow
comments. pg_bsd_indent has a fla
On Wed, Aug 16, 2023 at 01:15:55PM -0700, Peter Geoghegan wrote:
> On Tue, Aug 15, 2023 at 1:31 PM Nathan Bossart
> wrote:
>> Should we add those? Patch attached.
>
> I think that that makes sense.
Committed.
> I just don't want to normalize updating
> .git-blame-ignore-revs very frequently.
On 2020-Aug-12, Andres Freund wrote:
> Is there any reason we don't just automatically run pgindent regularly?
> Like once a week? And also update typedefs.list automatically, while
> we're at it?
Seconded.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24
Hi Andres,
On Wed, Aug 12, 2020 at 3:34 PM Andres Freund wrote:
>
> Hi,
>
> When developing patches I find it fairly painful that I cannot re-indent
> patches with pgindent without also seeing a lot of indentation changes
> in unmodified parts of files. It is easy enough ([1]) to only re-indent
>
Hi,
On 2020-08-12 16:08:50 -0700, Jesse Zhang wrote:
> On Wed, Aug 12, 2020 at 3:34 PM Andres Freund wrote:
> >
> > Hi,
> >
> > When developing patches I find it fairly painful that I cannot re-indent
> > patches with pgindent without also seeing a lot of indentation changes
> > in unmodified part
Jesse Zhang writes:
> On Wed, Aug 12, 2020 at 3:34 PM Andres Freund wrote:
>> Is there any reason we don't just automatically run pgindent regularly?
>> Like once a week? And also update typedefs.list automatically, while
>> we're at it?
> You know what's better than weekly? Every check-in.
I'm
Andres Freund writes:
> Unfortunately that is, with the current tooling, not entirely trivial to
> do so completely. The way we generate the list of known typedefs
> unfortunately depends on the platform a build is run on. Therefore the
> buildfarm collects a number of the generated list of typede
On Wed, Aug 12, 2020 at 06:53:25PM -0400, Alvaro Herrera wrote:
> On 2020-Aug-12, Andres Freund wrote:
>> Is there any reason we don't just automatically run pgindent regularly?
>> Like once a week? And also update typedefs.list automatically, while
>> we're at it?
>
> Seconded.
Thirded.
--
Micha
On Wed, Aug 12, 2020 at 07:47:01PM -0400, Tom Lane wrote:
> Jesse Zhang writes:
> > On Wed, Aug 12, 2020 at 3:34 PM Andres Freund wrote:
> >> Is there any reason we don't just automatically run pgindent regularly?
> >> Like once a week? And also update typedefs.list automatically, while
> >> we're
Noah Misch writes:
> On Wed, Aug 12, 2020 at 07:47:01PM -0400, Tom Lane wrote:
>> If the workflow is commit first and re-indent later, then we can always
>> revert the pgindent commit and clean things up manually; but an auto
>> re-indent during commit wouldn't provide that history.
> There are c
On Thu, Aug 13, 2020 at 12:08:36AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Aug 12, 2020 at 07:47:01PM -0400, Tom Lane wrote:
> >> If the workflow is commit first and re-indent later, then we can always
> >> revert the pgindent commit and clean things up manually; but an auto
> >> r
Noah Misch writes:
> ... Another advantage of master-only is a guarantee against
> disrupting time-critical patches. (It would be ugly to push back branches and
> sort out the master push later, but it doesn't obstruct the mission.)
Hm, doesn't it? I had the idea that "git push" is atomic --- e
On Thu, Aug 13, 2020 at 01:14:33AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > ... Another advantage of master-only is a guarantee against
> > disrupting time-critical patches. (It would be ugly to push back branches
> > and
> > sort out the master push later, but it doesn't obstruct the mis
On Wed, Aug 12, 2020 at 10:14 PM Tom Lane wrote:
>
> Noah Misch writes:
> > ... Another advantage of master-only is a guarantee against
> > disrupting time-critical patches. (It would be ugly to push back branches
> > and
> > sort out the master push later, but it doesn't obstruct the mission.)
On Thu, Aug 13, 2020 at 6:08 AM Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Aug 12, 2020 at 07:47:01PM -0400, Tom Lane wrote:
> >> If the workflow is commit first and re-indent later, then we can always
> >> revert the pgindent commit and clean things up manually; but an auto
> >> re-indent
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> There's another option here as well, that is a bit "softer", is to use a
> pre-commit hook.
Yeah, +1 on a pre-commit idea to help address this. I certainly agree
with Andres that it's quite annoying to deal with commits coming in that
a
Stephen Frost writes:
> So, in our world, wouldn't this translate to 'make cfbot complain'?
> I'm definitely a fan of the idea of having cfbot flag these and then we
> maybe get to a point where it's not the committers dealing with fixing
> patches that weren't pgindent'd properly, it's the actua
On Thu, Aug 13, 2020 at 6:30 PM Stephen Frost wrote:
>
> * Magnus Hagander (mag...@hagander.net) wrote:
>
> > There are many solutions that do such things but that do it in the
> "github
> > workflow" way, which is they do change -> commit -> create pull request,
> > and then somebody eyeballs th
On Wed, Aug 12, 2020 at 7:47 PM Tom Lane wrote:
> I'm not in favor of unsupervised pgindent runs, really. It can do a lot
> of damage to code that was written without thinking about it --- in
> particular, it'll make a hash of comment blocks that were manually
> formatted and not protected with d
On Thu, Aug 13, 2020 at 12:30 PM Stephen Frost wrote:
> So, in our world, wouldn't this translate to 'make cfbot complain'?
This seems like it would be useful, but we'd have to figure out what
to do about typedefs.list. If the patch is indented with the current
one (which is auto-generated by the
Robert Haas writes:
> I am not sure whether weekly or after-every-commit pgindent runs is a
> good idea, but I think we should try to do it once a month or so. It's
> too annoying otherwise. I could go either way on the question of
> automation.
The traditional reason for not doing pgindent too o
On Thu, Aug 13, 2020 at 3:47 PM Tom Lane wrote:
> The traditional reason for not doing pgindent too often has been that
> it'd cause more work for people who have to rebase their patches over
> pgindent's results. If we want to do it more often, then in order to
> respond to that concern, I think
Hi,
On 2020-08-13 12:50:16 -0400, Tom Lane wrote:
> Stephen Frost writes:
> > So, in our world, wouldn't this translate to 'make cfbot complain'?
>
> > I'm definitely a fan of the idea of having cfbot flag these and then we
> > maybe get to a point where it's not the committers dealing with fixi
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Aug 13, 2020 at 12:30 PM Stephen Frost wrote:
> > So, in our world, wouldn't this translate to 'make cfbot complain'?
>
> This seems like it would be useful, but we'd have to figure out what
> to do about typedefs.list. If the pat
On 2020-Aug-13, Stephen Frost wrote:
> For my 2c, anyway, I like the idea of having folks update the typedefs
> themselves when they've got a patch that needs a new typedef to be
> indented correctly.
Well, let's for starters encourage committers to update typedefs.
Personally I've stayed away fr
On 2020-Aug-13, Magnus Hagander wrote:
> That is:
> 1. Whenever a patch is pushed on master on the main repo a process kicked
> off (or maybe wait 5 minutes to coalesce multiple patches if there are)
> 2. This process checks out master, and runs pgindent on it
> 3. When done, this gets committed t
On Sat, Aug 15, 2020 at 1:57 AM Alvaro Herrera wrote:
>
> On 2020-Aug-13, Magnus Hagander wrote:
>
> > That is:
> > 1. Whenever a patch is pushed on master on the main repo a process kicked
> > off (or maybe wait 5 minutes to coalesce multiple patches if there are)
> > 2. This process checks out m
On 2020-08-13 00:34, Andres Freund wrote:
I e.g. just re-indented patch 0001 of my GetSnapshotData() series and
most of the hunks were entirely unrelated. Despite the development
window for 14 having only relatively recently opened. Based on my
experience it tends to get worse over time.
Do we
Hi,
On 2020-08-15 13:47:41 +0200, Peter Eisentraut wrote:
> On 2020-08-13 00:34, Andres Freund wrote:
> > I e.g. just re-indented patch 0001 of my GetSnapshotData() series and
> > most of the hunks were entirely unrelated. Despite the development
> > window for 14 having only relatively recently o
Andres Freund writes:
> One thing is that some here are actively against manually adding entries
> to typedefs.list.
I've been of the opinion that it's pointless to do so under the current
regime where (a) only a few people do that and (b) we only officially
re-indent once a year anyway. When I
On Sat, Aug 15, 2020 at 01:44:34PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > Without a properly indented baseline that's hard to do, because it'll
> > cause damage all over. So I don't think we easily can start just there -
> > we'd first need to re-indent everything.
>
> Well, we can ce
Hi,
On 2020-08-17 13:54:15 -0400, Bruce Momjian wrote:
> On Sat, Aug 15, 2020 at 01:44:34PM -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Without a properly indented baseline that's hard to do, because it'll
> > > cause damage all over. So I don't think we easily can start just there -
>
Bruce Momjian writes:
> On Sat, Aug 15, 2020 at 01:44:34PM -0400, Tom Lane wrote:
>> Well, we can certainly do a tree-wide re-indent anytime we're ready.
>> I doubt it would be very painful right now, with so little new work
>> since the last run.
> Uh, I thought Tom was saying we need to reinden
Hi,
On 2020-08-15 13:44:34 -0400, Tom Lane wrote:
> Andres Freund writes:
> > One thing is that some here are actively against manually adding entries
> > to typedefs.list.
>
> I've been of the opinion that it's pointless to do so under the current
> regime where (a) only a few people do that an
Andres Freund writes:
> On 2020-08-15 13:44:34 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> One thing is that some here are actively against manually adding entries
>>> to typedefs.list.
>> I've been of the opinion that it's pointless to do so under the current
>> regime where (a) only a
On Fri, Aug 14, 2020 at 10:26 PM Alvaro Herrera
wrote:
> On 2020-Aug-13, Magnus Hagander wrote:
>
> > That is:
> > 1. Whenever a patch is pushed on master on the main repo a process kicked
> > off (or maybe wait 5 minutes to coalesce multiple patches if there are)
> > 2. This process checks out m
On Sat, Jun 17, 2023 at 7:08 AM Andrew Dunstan wrote:
> I have set up a new buildfarm animal called koel which will run the module.
I'm starting to have doubts about this policy. There have now been
quite a few follow-up "fixes" to indentation issues that koel
complained about. None of these fixu
Hi,
On 2023-08-11 13:59:40 -0700, Peter Geoghegan wrote:
> On Sat, Jun 17, 2023 at 7:08 AM Andrew Dunstan wrote:
> > I have set up a new buildfarm animal called koel which will run the module.
>
> I'm starting to have doubts about this policy. There have now been
> quite a few follow-up "fixes"
On Fri, Aug 11, 2023 at 2:25 PM Andres Freund wrote:
> > I don't think that it makes sense to invent yet another rule for
> > .git-blame-ignore-revs, though. Will we need another buildfarm member
> > to enforce that rule, too?
>
> We could a test that fails when there's some mis-indented code. Tha
Peter Geoghegan writes:
> On Fri, Aug 11, 2023 at 2:25 PM Andres Freund wrote:
>> We could a test that fails when there's some mis-indented code. That seems
>> like it might catch things earlier?
+1 for including this in CI tests
> It definitely would. That would go a long way towards addressin
On Fri, Aug 11, 2023 at 3:30 PM Tom Lane wrote:
> No. I presume koel is using src/tools/pgindent/typedefs.list,
> which has always been the "canonical" list but up to now we've
> been lazy about maintaining it. Part of the new regime is that
> typedefs.list should now be updated on-the-fly by pa
Peter Geoghegan writes:
> My workflow up until now has avoiding making updates to typedefs.list
> in patches. I only update typedefs locally, for long enough to indent
> my code. The final patch doesn't retain any typedefs.list changes.
Yeah, I've done the same and will have to stop.
> I guess t
Peter Geoghegan writes:
> I'm starting to have doubts about this policy. There have now been
> quite a few follow-up "fixes" to indentation issues that koel
> complained about. None of these fixups have been included in
> .git-blame-ignore-revs. If things continue like this then "git blame"
> is b
On Fri, 11 Aug 2023 at 23:00, Peter Geoghegan wrote:
> I'm starting to have doubts about this policy. There have now been
> quite a few follow-up "fixes" to indentation issues that koel
> complained about.
I think one thing that would help a lot in reducing the is for
committers to set up the loc
Hi,
On 2023-08-11 18:30:02 -0400, Tom Lane wrote:
> Peter Geoghegan writes:
> > On Fri, Aug 11, 2023 at 2:25 PM Andres Freund wrote:
> >> We could a test that fails when there's some mis-indented code. That seems
> >> like it might catch things earlier?
>
> +1 for including this in CI tests
I
Andres Freund writes:
> On 2023-08-11 18:30:02 -0400, Tom Lane wrote:
>> +1 for including this in CI tests
> I didn't even mean CI - I meant 'make check-world' / 'meson test'. Which of
> course would include CI automatically.
Hmm. I'm allergic to anything that significantly increases the cost
o
On Fri, Aug 11, 2023 at 08:11:34PM -0400, Tom Lane wrote:
> Hmm. I'm allergic to anything that significantly increases the cost
> of check-world, and this seems like it'd do that.
>
> Maybe we could automate it, but not as part of check-world per se?
It does not have to be part of check-world by
Hi,
On 2023-08-11 20:11:34 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-08-11 18:30:02 -0400, Tom Lane wrote:
> >> +1 for including this in CI tests
>
> > I didn't even mean CI - I meant 'make check-world' / 'meson test'. Which of
> > course would include CI automatically.
>
> Hmm.
On 2023-08-11 Fr 19:17, Tom Lane wrote:
Peter Geoghegan writes:
I'm starting to have doubts about this policy. There have now been
quite a few follow-up "fixes" to indentation issues that koel
complained about. None of these fixups have been included in
.git-blame-ignore-revs. If things contin
On 2023-08-11 Fr 19:02, Tom Lane wrote:
Peter Geoghegan writes:
My workflow up until now has avoiding making updates to typedefs.list
in patches. I only update typedefs locally, for long enough to indent
my code. The final patch doesn't retain any typedefs.list changes.
Yeah, I've done the sa
Hi,
On 2023-08-12 17:03:37 -0400, Andrew Dunstan wrote:
> On 2023-08-11 Fr 19:02, Tom Lane wrote:
> > Peter Geoghegan writes:
> > > My workflow up until now has avoiding making updates to typedefs.list
> > > in patches. I only update typedefs locally, for long enough to indent
> > > my code. The
Andres Freund writes:
> On 2023-08-12 17:03:37 -0400, Andrew Dunstan wrote:
>> My recollection is that missing typedefs cause indentation that kinda sticks
>> out like a sore thumb.
Yeah, it's usually pretty obvious: "typedef *var" gets changed to
"typedef * var", and similar oddities.
> It's a
On Sat, Aug 12, 2023 at 3:47 PM Tom Lane wrote:
> > It's a somewhat annoying task though, find all the typedefs, add them to the
> > right place in the file (we have an out of order entry right now). I think a
> > script that *adds* (but doesn't remove) local typedefs would make this less
> > pain
Peter Geoghegan writes:
> We seem to be seriously contemplating making every patch author do
> this every time they need to get the tests to pass (after adding or
> renaming a struct). Is that really an improvement over the old status
> quo?
Hm. I was envisioning that we should expect committers
On Sat, Aug 12, 2023 at 5:20 PM Tom Lane wrote:
> Hm. I was envisioning that we should expect committers to deal
> with this, not original patch submitters. So that's an argument
> against including it in the CI tests. But I'm in favor of anything
> we can do to make it more painless for commit
On 2023-08-12 Sa 20:53, Peter Geoghegan wrote:
On Sat, Aug 12, 2023 at 5:20 PM Tom Lane wrote:
Hm. I was envisioning that we should expect committers to deal
with this, not original patch submitters. So that's an argument
against including it in the CI tests. But I'm in favor of anything
we
On Sun, Aug 13, 2023 at 10:33:21AM -0400, Andrew Dunstan wrote:
> After I'd been caught by this once or twice I implemented a git hook test
> for that too - in fact it was the first hook I did. It's not perfect but
> it's saved me a couple of times:
>
> check_catalog_version () {
I find that pret
On 12.08.23 23:14, Andres Freund wrote:
It's a somewhat annoying task though, find all the typedefs, add them to the
right place in the file (we have an out of order entry right now). I think a
script that*adds* (but doesn't remove) local typedefs would make this less
painful.
I was puzzled on
On 12.08.23 02:11, Tom Lane wrote:
Andres Freund writes:
On 2023-08-11 18:30:02 -0400, Tom Lane wrote:
+1 for including this in CI tests
I didn't even mean CI - I meant 'make check-world' / 'meson test'. Which of
course would include CI automatically.
Hmm. I'm allergic to anything that s
On 2023-08-14 Mo 10:04, Peter Eisentraut wrote:
On 12.08.23 23:14, Andres Freund wrote:
It's a somewhat annoying task though, find all the typedefs, add them
to the
right place in the file (we have an out of order entry right now). I
think a
script that*adds* (but doesn't remove) local typede
On Fri, Aug 11, 2023 at 01:59:40PM -0700, Peter Geoghegan wrote:
> I'm starting to have doubts about this policy. There have now been
> quite a few follow-up "fixes" to indentation issues that koel
> complained about. None of these fixups have been included in
> .git-blame-ignore-revs. If things co
On Tue, Aug 15, 2023 at 1:31 PM Nathan Bossart wrote:
> Should we add those? Patch attached.
I think that that makes sense. I just don't want to normalize updating
.git-blame-ignore-revs very frequently. (Actually, it's more like I
don't want to normalize any scheme that makes updating the ignor
Now that the PG16 feature freeze happened I think it's time to bump
this thread again. As far as I remember everyone that responded (even
previously silent people) were themselves proponents of being more
strict around pgindent.
I think there's two things needed to actually start doing this:
1. We
On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
> For 2 the upstream thread listed two approaches:
> a. Install a pre-receive git hook on the git server that rejects
> pushes to master that are not indented
> b. Add a test suite that checks if the code is correctly indented, so
> the
On 2023-04-22 Sa 04:50, Michael Paquier wrote:
On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
For 2 the upstream thread listed two approaches:
a. Install a pre-receive git hook on the git server that rejects
pushes to master that are not indented
b. Add a test suite that checks
On Sat, Apr 22, 2023 at 07:42:36AM -0400, Andrew Dunstan wrote:
> Perhaps we should start with a buildfarm module, which would run pg_indent
> --show-diff.
Nice, I didn't know this one and it has been mentioned a bit on this
thread. Indeed, it is possible to just rely on that.
--
Michael
signat
On Sat, Apr 22, 2023 at 1:42 PM Andrew Dunstan wrote:
>
>
> On 2023-04-22 Sa 04:50, Michael Paquier wrote:
>
> On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
>
> For 2 the upstream thread listed two approaches:
> a. Install a pre-receive git hook on the git server that rejects
> pu
On Tue, Feb 7, 2023 at 5:43 AM Noah Misch wrote:
>
> On Mon, Feb 06, 2023 at 06:17:02PM +0100, Peter Eisentraut wrote:
> > Also, pgindent takes tens of seconds to run, so hooking that into the git
> > push process would slow this down quite a bit.
>
> The pre-receive hook would do a full pgindent
On 2023-04-22 Sa 08:47, Magnus Hagander wrote:
On Sat, Apr 22, 2023 at 1:42 PM Andrew Dunstan wrote:
On 2023-04-22 Sa 04:50, Michael Paquier wrote:
On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
For 2 the upstream thread listed two approaches:
a. Install a pre-receive git ho
Magnus Hagander writes:
> On Sat, Apr 22, 2023 at 1:42 PM Andrew Dunstan wrote:
>> For 2 the upstream thread listed two approaches:
>> a. Install a pre-receive git hook on the git server that rejects
>> pushes to master that are not indented
>> b. Add a test suite that checks if the code is corre
Jelte Fennema writes:
> I think there's two things needed to actually start doing this:
> 1. We need to reindent the tree to create an indented baseline
As far as (1) goes, I've been holding off on that because there
are some large patches that still seem in danger of getting
reverted, notably 24
On 2023-04-22 Sa 10:39, Tom Lane wrote:
Another obstacle in the way of (1) is that there was some discussion
of changing perltidy version and/or options. But I don't believe
we have a final proposal on that, much less committed code.
Well, I posted a fairly concrete suggestion with an examp
Andrew Dunstan writes:
> On 2023-04-22 Sa 10:39, Tom Lane wrote:
>> Another obstacle in the way of (1) is that there was some discussion
>> of changing perltidy version and/or options. But I don't believe
>> we have a final proposal on that, much less committed code.
> Well, I posted a fairly co
On 2023-04-22 Sa 11:37, Tom Lane wrote:
Andrew Dunstan writes:
On 2023-04-22 Sa 10:39, Tom Lane wrote:
Another obstacle in the way of (1) is that there was some discussion
of changing perltidy version and/or options. But I don't believe
we have a final proposal on that, much less committed c
Andrew Dunstan writes:
> On 2023-04-22 Sa 11:37, Tom Lane wrote:
>> * I see that there's now a 20230309 release, should we consider that
>> instead?
> A test I just ran gave identical results to those from 20221112
Cool, let's use perltidy 20230309 then.
> The great advantage of not doing this
(Given that another commentator is "absolutely against" a hook, this message
is mostly for readers considering this for other projects.)
On Sat, Apr 22, 2023 at 03:23:59PM +0200, Magnus Hagander wrote:
> On Tue, Feb 7, 2023 at 5:43 AM Noah Misch wrote:
> > On Mon, Feb 06, 2023 at 06:17:02PM +0100
Noah Misch writes:
> - skip if the break-glass "pgindent: no" appears in a commit message
There are two things that bother me about putting this functionality
into a server hook, beyond the possible speed issue:
* The risk of failure. I don't have a terribly difficult time imagining
situations
On Sat, Apr 22, 2023 at 04:15:23PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > - skip if the break-glass "pgindent: no" appears in a commit message
>
> There are two things that bother me about putting this functionality
> into a server hook, beyond the possible speed issue:
>
> * The risk o
On 2023-04-22 Sa 15:58, Tom Lane wrote:
Andrew Dunstan writes:
On 2023-04-22 Sa 11:37, Tom Lane wrote:
* I see that there's now a 20230309 release, should we consider that
instead?
A test I just ran gave identical results to those from 20221112
Cool, let's use perltidy 20230309 then.
OK
On 2023-04-22 Sa 16:15, Tom Lane wrote:
Noah Misch writes:
- skip if the break-glass "pgindent: no" appears in a commit message
There are two things that bother me about putting this functionality
into a server hook, beyond the possible speed issue:
* The risk of failure. I don't have a ter
Andrew Dunstan writes:
> On 2023-04-22 Sa 15:58, Tom Lane wrote:
>> Cool, let's use perltidy 20230309 then.
> OK, so when would we do this? The change to 20230309 + valign changes is
> fairly large:
I think we could go ahead and commit the perltidyrc and README changes
now. But the ensuing ref
On Sun, 23 Apr 2023 at 17:16, Tom Lane wrote:
> I think we could go ahead and commit the perltidyrc and README changes
> now. But the ensuing reformatting should happen as part of the mass
> pgindent run, probably next month sometime.
I think it's better to make the changes close together, not w
On Sat, Apr 22, 2023 at 4:12 PM Andrew Dunstan wrote:
>
>
> On 2023-04-22 Sa 08:47, Magnus Hagander wrote:
>
> On Sat, Apr 22, 2023 at 1:42 PM Andrew Dunstan wrote:
>
> On 2023-04-22 Sa 04:50, Michael Paquier wrote:
>
> On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
>
> For 2 the
On Sat, Apr 22, 2023 at 9:59 PM Noah Misch wrote:
>
> (Given that another commentator is "absolutely against" a hook, this message
> is mostly for readers considering this for other projects.)
>
> On Sat, Apr 22, 2023 at 03:23:59PM +0200, Magnus Hagander wrote:
> > On Tue, Feb 7, 2023 at 5:43 AM N
On 23.04.23 17:29, Jelte Fennema wrote:
On Sun, 23 Apr 2023 at 17:16, Tom Lane wrote:
I think we could go ahead and commit the perltidyrc and README changes
now. But the ensuing reformatting should happen as part of the mass
pgindent run, probably next month sometime.
I think it's better to
Peter Eisentraut writes:
> Does anyone find perltidy useful? To me, it functions more like a
> JavaScript compiler in that once you process the source code, it is no
> longer useful for manual editing. If we are going to have the buildfarm
> check indentation and that is going to be extended
On 24.04.23 16:14, Tom Lane wrote:
Peter Eisentraut writes:
Does anyone find perltidy useful? To me, it functions more like a
JavaScript compiler in that once you process the source code, it is no
longer useful for manual editing. If we are going to have the buildfarm
check indentation and th
Peter Eisentraut writes:
> On 24.04.23 16:14, Tom Lane wrote:
>> I certainly don't like its current behavior where adding/changing one
>> line can have side-effects on nearby lines. But we have a proposal
>> to clean that up, and I'm cautiously optimistic that it'll be better
>> in future. Did y
On 2023-04-26 We 09:27, Tom Lane wrote:
Peter Eisentraut writes:
On 24.04.23 16:14, Tom Lane wrote:
I certainly don't like its current behavior where adding/changing one
line can have side-effects on nearby lines. But we have a proposal
to clean that up, and I'm cautiously optimistic that it
Andrew Dunstan writes:
> On 2023-04-26 We 09:27, Tom Lane wrote:
>> Yeah, I agree, there is no case where that doesn't suck. I don't
>> mind it imposing specific placements of brackets and so on ---
>> that's very analogous to what pgindent will do. But it likes to
>> re-flow comma-separated lis
On 2023-Feb-05, Andrew Dunstan wrote:
> So here's a diff made from running perltidy v20221112 with the additional
> setting --valign-exclusion-list=", = => || && if unless"
I ran this experimentally with perltidy 20230309, and compared that with
the --novalign behavior (not to propose the latter
On Wed, Apr 26, 2023 at 03:44:47PM -0400, Andrew Dunstan wrote:
> On 2023-04-26 We 09:27, Tom Lane wrote:
> I doubt there's something like that. You can freeze arbitrary blocks of code
> like this (from the manual)
>
> #<<< format skipping: do not let perltidy change my nice formatting
>
On 2023-04-28 Fr 05:25, Alvaro Herrera wrote:
On 2023-Feb-05, Andrew Dunstan wrote:
So here's a diff made from running perltidy v20221112 with the additional
setting --valign-exclusion-list=", = => || && if unless"
I ran this experimentally with perltidy 20230309, and compared that with
the -
On 2023-04-28 Fr 14:08, Bruce Momjian wrote:
On Wed, Apr 26, 2023 at 03:44:47PM -0400, Andrew Dunstan wrote:
On 2023-04-26 We 09:27, Tom Lane wrote:
I doubt there's something like that. You can freeze arbitrary blocks of code
like this (from the manual)
#<<< format skipping: do not let perlti
Andrew Dunstan writes:
> On 2023-04-28 Fr 14:08, Bruce Momjian wrote:
>> Can those comments be added by a preprocessor before calling perltidy,
>> and then removed on completion?
> I imagine so, but we'd need a way of determining algorithmically which
> lines to protect. That might not be at all
I wrote:
> Andrew Dunstan writes:
>> I doubt there's something like that.
> I had a read-through of the latest version's man page, and found
> this promising-looking entry:
> -boc, --break-at-old-comma-breakpoints
Sadly, this seems completely not ready for prime time. I experimented
with
On 2023-05-17 We 17:10, Tom Lane wrote:
I wrote:
Andrew Dunstan writes:
I doubt there's something like that.
I had a read-through of the latest version's man page, and found
this promising-looking entry:
-boc, --break-at-old-comma-breakpoints
Sadly, this seems completely not ready f
On Sat, 22 Apr 2023 at 13:42, Andrew Dunstan wrote:
> Perhaps we should start with a buildfarm module, which would run pg_indent
> --show-diff. That would only need to run on one animal, so a failure wouldn't
> send the whole buildfarm red. This would be pretty easy to do.
Just to be clear on w
201 - 300 of 307 matches
Mail list logo
