Andrew Dunstan writes:
> On 6/28/21 10:44 AM, Tom Lane wrote:
>> Wait ... I did already, at 5a0f1c8c0. Are you sure you were indenting
>> current HEAD?
> No, see revised patch. I posted at 10.13
Right, new version looks better.
regards, tom lane
On 6/28/21 10:44 AM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan writes:
>>> I'll let Tom speak for himself, but I somewhat doubt he meant the code
>>> to stay badly indented for more than a short period of time.
>> I did not. If you can give me an hour or so, I'll get the patch
>> I previousl
I wrote:
> Andrew Dunstan writes:
>> I'll let Tom speak for himself, but I somewhat doubt he meant the code
>> to stay badly indented for more than a short period of time.
> I did not. If you can give me an hour or so, I'll get the patch
> I previously proposed [1] committed, and then this issue
Andrew Dunstan writes:
> On 6/28/21 8:52 AM, David Rowley wrote:
>> I wasn't too sure about the status of this one. Michael did mention it
>> in [1], but Tom mentioned that was on purpose to ease backpatching.
>> I'm not too clear on if Tom intended it should stay unindented until
>> "rewriting th
On 6/28/21 8:29 AM, Andrew Dunstan wrote:
> Here's the diff from a pgindent run. The results look kosher to me - I
> had to do a little surgery on queryjumble.h due to it having an unused
> typedef.
>
>
This time run against the right branch ..
cheers
andrew
--
Andre
On 6/28/21 8:52 AM, David Rowley wrote:
> On Tue, 29 Jun 2021 at 00:29, Andrew Dunstan wrote:
>> Here's the diff from a pgindent run.
> --- a/src/backend/commands/policy.c
> +++ b/src/backend/commands/policy.c
> @@ -587,65 +587,65 @@ RemoveRoleFromObjectPolicy(Oid rol
On Tue, 29 Jun 2021 at 00:29, Andrew Dunstan wrote:
> Here's the diff from a pgindent run.
--- a/src/backend/commands/policy.c
+++ b/src/backend/commands/policy.c
@@ -587,65 +587,65 @@ RemoveRoleFromObjectPolicy(Oid roleid, Oid
classid, Oid policy_id)
/* If any roles remain, update th
Here's the diff from a pgindent run. The results look kosher to me - I
had to do a little surgery on queryjumble.h due to it having an unused
typedef.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/
Em qua, 22 de mai de 2019 às 14:08, Tom Lane escreveu:
>
> I wrote:
> > Hearing no objections, I'll plan on running pgindent tomorrow sometime.
>
> And done.
>
> > The new underlying pg_bsd_indent (2.1) is available now from
> > https://git.postgresql.org/git/pg_bsd_indent.git
>
> Please update yo
Peter Eisentraut writes:
> In my experience, changes to function declarations in header files
> happen a lot in forks. So applying the pgindent change to backbranches
> would cause some trouble.
> On the other hand, it seems to me that patches that we backpatch between
> PostgreSQL branches shou
On 2019-05-21 23:46, Tom Lane wrote:
>> Would we want to also apply this to the back branches to avoid spurious
>> conflicts?
> I think we should hold off on any talk of that until we get some results
> from Mark Dilger (or anyone else) on how much pain it would cause for
> people carrying private
On Wed, May 22, 2019 at 10:07 AM Tom Lane wrote:
>
> I wrote:
> > Hearing no objections, I'll plan on running pgindent tomorrow sometime.
>
> And done.
>
> > The new underlying pg_bsd_indent (2.1) is available now from
> > https://git.postgresql.org/git/pg_bsd_indent.git
>
> Please update your loc
I wrote:
> Hearing no objections, I'll plan on running pgindent tomorrow sometime.
And done.
> The new underlying pg_bsd_indent (2.1) is available now from
> https://git.postgresql.org/git/pg_bsd_indent.git
Please update your local copy if you have one.
regards, tom lane
Andres Freund writes:
> On 2019-05-17 10:29:46 -0400, Tom Lane wrote:
>> We should do a pgindent run fairly soon, so that people with patches
>> awaiting the next CF will have plenty of time to rebase them as
>> necessary.
>> I don't want to do it right this min
Mark Dilger writes:
> On May 17, 2019, at 12:10 PM, Tom Lane wrote:
>> Anybody around here got large patches they're carrying against
>> back branches, that they could try reapplying after running
>> a newer version of pgindent?
> I have forks of 9.1 and 9.5 that each amount to large changes
> a
> On May 17, 2019, at 12:10 PM, Tom Lane wrote:
>
> Andres Freund writes:
>> On 2019-05-17 13:47:02 -0400, Tom Lane wrote:
>>> I dunno, how far back are you thinking? I've occasionally wished we
>>> could reindent all the back branches to match HEAD, but realistically,
>>> people carrying ou
Andres Freund writes:
> On 2019-05-17 13:47:02 -0400, Tom Lane wrote:
>> I dunno, how far back are you thinking? I've occasionally wished we
>> could reindent all the back branches to match HEAD, but realistically,
>> people carrying out-of-tree patches would scream.
> I somehow thought we'd bac
Hi,
On 2019-05-17 13:47:02 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Would we want to also apply this to the back branches to avoid spurious
> > conflicts?
>
> I dunno, how far back are you thinking? I've occasionally wished we
> could reindent all the back branches to match HEAD, but
On Fri, May 17, 2019 at 01:47:02PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-17 10:29:46 -0400, Tom Lane wrote:
> >> Also, how do people feel about adopting the function prototype
> >> indenting change discussed in
> >> https://www.postgresql.org/message-id/flat/CAEepm%3D0P3FeT
Andres Freund writes:
> On 2019-05-17 10:29:46 -0400, Tom Lane wrote:
>> Also, how do people feel about adopting the function prototype
>> indenting change discussed in
>> https://www.postgresql.org/message-id/flat/CAEepm%3D0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug%40mail.gmail.com
> I think i
Hi,
On 2019-05-17 10:29:46 -0400, Tom Lane wrote:
> We should do a pgindent run fairly soon, so that people with patches
> awaiting the next CF will have plenty of time to rebase them as
> necessary.
+1
> I don't want to do it right this minute, to avoid making trouble for the
On Fri, May 17, 2019 at 10:29:46AM -0400, Tom Lane wrote:
> We should do a pgindent run fairly soon, so that people with patches
> awaiting the next CF will have plenty of time to rebase them as necessary.
> I don't want to do it right this minute, to avoid making trouble for the
&g
We should do a pgindent run fairly soon, so that people with patches
awaiting the next CF will have plenty of time to rebase them as necessary.
I don't want to do it right this minute, to avoid making trouble for the
several urgent patches we're trying to get done before Monday's b
Teodor Sigaev writes:
>> If there are large refactoring or bug-fix patches that haven't landed
>> yet, then it'd be appropriate to wait for those to get in, but I'm not
>> aware of such at the moment.
> Pls, wait
> https://www.postgresql.org/message-id/9c63951d-7696-ecbb-b832-70db7ed3f39b%40sigae
If there are large refactoring or bug-fix patches that haven't landed
yet, then it'd be appropriate to wait for those to get in, but I'm not
aware of such at the moment.
Pls, wait
https://www.postgresql.org/message-id/9c63951d-7696-ecbb-b832-70db7ed3f39b%40sigaev.ru
Thank you.
--
Teodor Sigaev
On Tue, Apr 17, 2018 at 12:57 PM, Tom Lane wrote:
> Now that feature freeze is past, I wonder if it's time to run pgindent.
+1
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Now that feature freeze is past, I wonder if it's time to run pgindent.
Last year we did a run immediately after beta1, plus one just before
branching off REL_10_STABLE. The value of an early run, IMO, is to
get most of the changes in place so that people have a stable base
to work from while reb
On January 24, 2018 11:34:07 AM PST, Tom Lane wrote:
>Andres Freund writes:
>> There'd be one or two edge cases of bad formatting, but the
>> end result would be far less painful than what we have today, were
>> basically nobody can format their patches without a lot of manual
>> cherry-picking
Andres Freund writes:
> FWIW, I think this problem could just as well be addressed with a few
> printing heuristics instead of actually needing an actual list of
> typedefs.
Step right up and implement that, and we'd all be happier. Certainly
the typedefs list is a pain in the rear.
> There'd b
On 2018-01-23 22:22:47 -0500, Bruce Momjian wrote:
> On Tue, Nov 28, 2017 at 04:38:12PM -0500, Tom Lane wrote:
> > Thomas Munro writes:
> > > On Wed, Nov 29, 2017 at 9:47 AM, Tom Lane wrote:
> > >> I think that'd be taking it too far, especially given that the dependency
> > >> on a typedefs list
On Tue, Nov 28, 2017 at 04:38:12PM -0500, Tom Lane wrote:
> Thomas Munro writes:
> > On Wed, Nov 29, 2017 at 9:47 AM, Tom Lane wrote:
> >> I think that'd be taking it too far, especially given that the dependency
> >> on a typedefs list means that the git hook might have a different idea
> >> of
> On Nov 28, 2017, at 2:57 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Nov 28, 2017, at 12:47 PM, Tom Lane wrote:
>>> I think that'd be taking it too far, especially given that the dependency
>>> on a typedefs list means that the git hook might have a different idea
>>> of what's correc
Mark Dilger writes:
>> On Nov 28, 2017, at 12:47 PM, Tom Lane wrote:
>> I think that'd be taking it too far, especially given that the dependency
>> on a typedefs list means that the git hook might have a different idea
>> of what's correctly indented than the committer does. It'd be very hard
>
> On Nov 28, 2017, at 12:47 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I have no objection, but if the community intends to keep everything
>> indented per project standards, why is there no git hook to reject
>> improperly indented code at commit time? I've suffered some pain
>> trying to
Thomas Munro writes:
> On Wed, Nov 29, 2017 at 9:47 AM, Tom Lane wrote:
>> I think that'd be taking it too far, especially given that the dependency
>> on a typedefs list means that the git hook might have a different idea
>> of what's correctly indented than the committer does. It'd be very har
On Wed, Nov 29, 2017 at 9:47 AM, Tom Lane wrote:
> Mark Dilger writes:
>> I have no objection, but if the community intends to keep everything
>> indented per project standards, why is there no git hook to reject
>> improperly indented code at commit time? I've suffered some pain
>> trying to me
Mark Dilger writes:
> I have no objection, but if the community intends to keep everything
> indented per project standards, why is there no git hook to reject
> improperly indented code at commit time? I've suffered some pain
> trying to merge code pre-global-indent-run into a branch
> post-glob
Andres Freund writes:
> On 2017-11-28 14:51:06 -0500, Robert Haas wrote:
>> If nobody minds too much, I'd like to update typedefs.list and
>> pgindent the whole tree again.
> +1.
OK by me --- I've several times restrained myself from just doing
an ad-hoc reindent on some of these files.
> On Nov 28, 2017, at 11:51 AM, Robert Haas wrote:
>
> If nobody minds too much, I'd like to update typedefs.list and
> pgindent the whole tree again. We've generally done a pretty good job
> with pgindenting patches as they are committed this cycle, but we're
> starting to accumulate things he
On Tue, Nov 28, 2017 at 2:51 PM, Robert Haas wrote:
> There are only four source files where more than a dozen lines will be
> touched...
...and of course by "four" I mean "five".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi,
On 2017-11-28 14:51:06 -0500, Robert Haas wrote:
> If nobody minds too much, I'd like to update typedefs.list and
> pgindent the whole tree again.
+1.
Greetings,
Andres Freund
If nobody minds too much, I'd like to update typedefs.list and
pgindent the whole tree again. We've generally done a pretty good job
with pgindenting patches as they are committed this cycle, but we're
starting to accumulate things here and there that are not indented
according to what pgindent li
42 matches
Mail list logo
