pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgindent versus struct members and typedefs
22+ messages / 5 participants
[nested] [flat]
* pgindent versus struct members and typedefs
@ 2025-12-02 22:00 Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Nathan Bossart @ 2025-12-02 22:00 UTC (permalink / raw)
To: Chao Li <li.evan.chao@gmail.com>; +Cc: Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Mon, Dec 01, 2025 at 05:04:23PM -0600, Nathan Bossart wrote:
> On Tue, Dec 02, 2025 at 05:35:34AM +0800, Chao Li wrote:
>> ```
>> + else if (entry->type == DSMR_ENTRY_TYPE_DSH &&
>> + entry->dsh.dsa_handle !=DSA_HANDLE_INVALID)
>> ```
>>
>> Missing a white space after !=.
>
> I agree, but for some reason, pgindent insists on removing that space. I'm
> leaving that for another thread.
So, this seems to have something to do with the struct member having the
same name as a typedef. If I rename the member, pgindent adds the space as
expected. Interestingly, changing the != to a == also fixes the spacing.
There are a couple of other examples in the code:
src/backend/storage/ipc/dsm_registry.c: entry->dsh.dsa_handle !=DSA_HANDLE_INVALID)
src/backend/replication/logical/logicalfuncs.c: ctx->options.output_type !=OUTPUT_PLUGIN_TEXTUAL_OUTPUT)
src/bin/pg_basebackup/pg_basebackup.c: if (state.manifest_file !=NULL)
src/bin/pg_basebackup/pg_basebackup.c: state->manifest_file !=NULL)
src/bin/pg_basebackup/pg_basebackup.c: else if (state->manifest_file !=NULL)
I used the following command to find these:
grep -E "!=[A-Za-z]" ./* -rI
AFAICT this is a special case of the note added to pgindent's README by
commit c4133ec:
pgindent will mangle both declaration and definition of a C function whose
name matches a typedef. Currently the best workaround is to choose
non-conflicting names.
I tried to fix pgindent for a few, but the code is basically impenetrable.
I didn't find any fixes upstream [0], either. As noted above, we could
also fix it by avoiding the naming conflicts. However, I can't imagine
that's worth the churn, and I've already spent way too much time on this,
so IMHO the best thing to do here is nothing.
[0] https://github.com/freebsd/freebsd-src/tree/main/usr.bin/indent
--
nathan
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2025-12-02 22:46 Chao Li <li.evan.chao@gmail.com>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Chao Li @ 2025-12-02 22:46 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
> On Dec 3, 2025, at 06:00, Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Mon, Dec 01, 2025 at 05:04:23PM -0600, Nathan Bossart wrote:
>> On Tue, Dec 02, 2025 at 05:35:34AM +0800, Chao Li wrote:
>>> ```
>>> + else if (entry->type == DSMR_ENTRY_TYPE_DSH &&
>>> + entry->dsh.dsa_handle !=DSA_HANDLE_INVALID)
>>> ```
>>>
>>> Missing a white space after !=.
>>
>> I agree, but for some reason, pgindent insists on removing that space. I'm
>> leaving that for another thread.
>
> So, this seems to have something to do with the struct member having the
> same name as a typedef. If I rename the member, pgindent adds the space as
> expected. Interestingly, changing the != to a == also fixes the spacing.
> There are a couple of other examples in the code:
>
> src/backend/storage/ipc/dsm_registry.c: entry->dsh.dsa_handle !=DSA_HANDLE_INVALID)
> src/backend/replication/logical/logicalfuncs.c: ctx->options.output_type !=OUTPUT_PLUGIN_TEXTUAL_OUTPUT)
> src/bin/pg_basebackup/pg_basebackup.c: if (state.manifest_file !=NULL)
> src/bin/pg_basebackup/pg_basebackup.c: state->manifest_file !=NULL)
> src/bin/pg_basebackup/pg_basebackup.c: else if (state->manifest_file !=NULL)
>
> I used the following command to find these:
>
> grep -E "!=[A-Za-z]" ./* -rI
>
> AFAICT this is a special case of the note added to pgindent's README by
> commit c4133ec:
>
> pgindent will mangle both declaration and definition of a C function whose
> name matches a typedef. Currently the best workaround is to choose
> non-conflicting names.
>
> I tried to fix pgindent for a few, but the code is basically impenetrable.
> I didn't find any fixes upstream [0], either. As noted above, we could
> also fix it by avoiding the naming conflicts. However, I can't imagine
> that's worth the churn, and I've already spent way too much time on this,
> so IMHO the best thing to do here is nothing.
>
I think that’s fine.
Actually I see the other problem with pgindent, where if a “else” clause contains a multiple-line comment and a single statement without braces, for example:
```
else
/*
* comment
*/
printf(…);
```
Then pgindent will blindly add an empty line after “else”, so we get:
```
else
/*
* comment
*/
printf(…);
```
I tried to fix but failed. For that problem, a solution is to add braces to the “else” clause.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2025-12-02 22:51 Tom Lane <tgl@sss.pgh.pa.us>
parent: Chao Li <li.evan.chao@gmail.com>
0 siblings, 2 replies; 22+ messages in thread
From: Tom Lane @ 2025-12-02 22:51 UTC (permalink / raw)
To: Chao Li <li.evan.chao@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Chao Li <li.evan.chao@gmail.com> writes:
> On Dec 3, 2025, at 06:00, Nathan Bossart <nathandbossart@gmail.com> wrote:
>> I tried to fix pgindent for a few, but the code is basically impenetrable.
>> I didn't find any fixes upstream [0], either. As noted above, we could
>> also fix it by avoiding the naming conflicts. However, I can't imagine
>> that's worth the churn, and I've already spent way too much time on this,
>> so IMHO the best thing to do here is nothing.
> I think that’s fine.
Agreed, not worth the trouble to fool with.
> Actually I see the other problem with pgindent, where if a “else” clause contains a multiple-line comment and a single statement without braces, for example:
> ...
> I tried to fix but failed. For that problem, a solution is to add braces to the “else” clause.
In this case, I think pgindent is indirectly enforcing good style.
I do not like omitting braces around anything that's more than one
line; readers have to pay close attention to whether the code is
doing what it was intended to.
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2025-12-02 23:06 Chao Li <li.evan.chao@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 22+ messages in thread
From: Chao Li @ 2025-12-02 23:06 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
> On Dec 3, 2025, at 06:51, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Chao Li <li.evan.chao@gmail.com> writes:
>> On Dec 3, 2025, at 06:00, Nathan Bossart <nathandbossart@gmail.com> wrote:
>>> I tried to fix pgindent for a few, but the code is basically impenetrable.
>>> I didn't find any fixes upstream [0], either. As noted above, we could
>>> also fix it by avoiding the naming conflicts. However, I can't imagine
>>> that's worth the churn, and I've already spent way too much time on this,
>>> so IMHO the best thing to do here is nothing.
>
>> I think that’s fine.
>
> Agreed, not worth the trouble to fool with.
>
>> Actually I see the other problem with pgindent, where if a “else” clause contains a multiple-line comment and a single statement without braces, for example:
>> ...
>> I tried to fix but failed. For that problem, a solution is to add braces to the “else” clause.
>
> In this case, I think pgindent is indirectly enforcing good style.
> I do not like omitting braces around anything that's more than one
> line; readers have to pay close attention to whether the code is
> doing what it was intended to.
>
For “one line”, do you mean only a single line of statement or one line statement plus one line comment?
To clarify the pgindnet problem, if we have a one-line comment plus one-line statement, for example:
```
else
/* one line comment */
printf(…);
```
In this case, pgindent will not add an empty line after “else”.
But I totally agree with you, when there is a multiple-line comment and a single statement, it's a good habit to add braces.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2025-12-02 23:13 Tom Lane <tgl@sss.pgh.pa.us>
parent: Chao Li <li.evan.chao@gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Tom Lane @ 2025-12-02 23:13 UTC (permalink / raw)
To: Chao Li <li.evan.chao@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Chao Li <li.evan.chao@gmail.com> writes:
>> On Dec 3, 2025, at 06:51, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In this case, I think pgindent is indirectly enforcing good style.
>> I do not like omitting braces around anything that's more than one
>> line; readers have to pay close attention to whether the code is
>> doing what it was intended to.
> For “one line”, do you mean only a single line of statement or one line statement plus one line comment?
In my head, a comment and a statement are two lines, and so need
wrapping braces as much as two statements would do. I realize that
C compilers think differently, but for readability and modifiability
reasons that's the approach I take.
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2025-12-02 23:31 Chao Li <li.evan.chao@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 22+ messages in thread
From: Chao Li @ 2025-12-02 23:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
> On Dec 3, 2025, at 07:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Chao Li <li.evan.chao@gmail.com> writes:
>>> On Dec 3, 2025, at 06:51, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> In this case, I think pgindent is indirectly enforcing good style.
>>> I do not like omitting braces around anything that's more than one
>>> line; readers have to pay close attention to whether the code is
>>> doing what it was intended to.
>
>> For “one line”, do you mean only a single line of statement or one line statement plus one line comment?
>
> In my head, a comment and a statement are two lines, and so need
> wrapping braces as much as two statements would do. I realize that
> C compilers think differently, but for readability and modifiability
> reasons that's the approach I take.
>
Totally agreed. In my first job at Lucent Technologies, the coding standard was that braces should always be added even if a clause has only one line of code. I remember one of the explanations was like, if braces has been added, then later when a new line of code is added to the clause, there is only one line of diff, otherwise braces need to be added, so it would be 3 lines of diffs.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2025-12-03 15:35 Andrew Dunstan <andrew@dunslane.net>
parent: Chao Li <li.evan.chao@gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Andrew Dunstan @ 2025-12-03 15:35 UTC (permalink / raw)
To: Chao Li <li.evan.chao@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 2025-12-02 Tu 6:31 PM, Chao Li wrote:
>
>> On Dec 3, 2025, at 07:13, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>
>> Chao Li<li.evan.chao@gmail.com> writes:
>>>> On Dec 3, 2025, at 06:51, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>>> In this case, I think pgindent is indirectly enforcing good style.
>>>> I do not like omitting braces around anything that's more than one
>>>> line; readers have to pay close attention to whether the code is
>>>> doing what it was intended to.
>>> For “one line”, do you mean only a single line of statement or one line statement plus one line comment?
>> In my head, a comment and a statement are two lines, and so need
>> wrapping braces as much as two statements would do. I realize that
>> C compilers think differently, but for readability and modifiability
>> reasons that's the approach I take.
>>
> Totally agreed. In my first job at Lucent Technologies, the coding standard was that braces should always be added even if a clause has only one line of code. I remember one of the explanations was like, if braces has been added, then later when a new line of code is added to the clause, there is only one line of diff, otherwise braces need to be added, so it would be 3 lines of diffs.
>
+1. One of the things I find particularly un-aesthetic is having some
branches of an if statement with braces and some without. We have lots
of cases of that, but I try to avoid it.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2025-12-03 17:25 Álvaro Herrera <alvherre@kurilemu.de>
parent: Andrew Dunstan <andrew@dunslane.net>
0 siblings, 0 replies; 22+ messages in thread
From: Álvaro Herrera @ 2025-12-03 17:25 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Chao Li <li.evan.chao@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Nathan Bossart <nathandbossart@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 2025-Dec-03, Andrew Dunstan wrote:
> +1. One of the things I find particularly un-aesthetic is having some
> branches of an if statement with braces and some without. We have lots of
> cases of that, but I try to avoid it.
I actually prefer that style: when there are only two branches, and the
other branch of the if is long, I put the short one first without
braces, and then braces around the long "else" one.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"The eagle never lost so much time, as
when he submitted to learn of the crow." (William Blake)
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-05 21:47 Nathan Bossart <nathandbossart@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 22+ messages in thread
From: Nathan Bossart @ 2026-05-05 21:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Dec 02, 2025 at 05:51:15PM -0500, Tom Lane wrote:
> Chao Li <li.evan.chao@gmail.com> writes:
>> On Dec 3, 2025, at 06:00, Nathan Bossart <nathandbossart@gmail.com> wrote:
>>> I tried to fix pgindent for a few, but the code is basically impenetrable.
>>> I didn't find any fixes upstream [0], either. As noted above, we could
>>> also fix it by avoiding the naming conflicts. However, I can't imagine
>>> that's worth the churn, and I've already spent way too much time on this,
>>> so IMHO the best thing to do here is nothing.
>
>> I think that’s fine.
>
> Agreed, not worth the trouble to fool with.
For fun, I spent some time with an AI tool to develop the attached fix for
this problem. The explanation seems reasonable to me, although I am by no
means a pgindent expert. When I looked at this in December, I did find
this similar commit from upstream [0], but I failed to make the connection
with last_u_d. 0002 is the result of a pgindent run after applying 0001.
You'll notice that it fixes the exact set of cases I found with grep
upthread.
[0] https://github.com/pstef/freebsd_indent/commit/afa2239
--
nathan
From 804bb1097a44cc35178f3e1de46d17422ce7b67f Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nathan@postgresql.org>
Date: Tue, 5 May 2026 16:03:13 -0500
Subject: [PATCH v1 1/2] pgindent: Fix spacing after != when member name
matches typedef.
When a struct member name matches a registered typedef, pgindent
removes the space after "!=" (and some other operators):
entry->dsh.dsa_handle !=DSA_HANDLE_INVALID
In lexi.c, when an identifier matches the typedef list, the code
sets last_u_d = true before jumping to found_typename. This flag
tells the lexer that the next operator should be treated as unary,
which is correct for type names (e.g., "Datum *x" needs * to be
unary, not multiplication).
However, found_typename has a guard that recognizes when a typedef
name appears after "." or "->": in that case, the name is a struct
member, not a type, so it's returned as a plain identifier. The
problem is that last_u_d has already been set to true and is never
corrected. This causes the next operator (e.g., "!=") to be
misclassified as unary, which suppresses the space after it.
To fix, only set last_u_d when the token won't be caught by the
guard, i.e., when it will actually be treated as a type name.
This also explains why "==" was not affected: the "==" case always
returns binary_op regardless of last_u_d, while "!=" checks
last_u_d to decide.
---
src/tools/pg_bsd_indent/lexi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/tools/pg_bsd_indent/lexi.c b/src/tools/pg_bsd_indent/lexi.c
index 943bf7ce6b0..e846188d6f4 100644
--- a/src/tools/pg_bsd_indent/lexi.c
+++ b/src/tools/pg_bsd_indent/lexi.c
@@ -363,7 +363,8 @@ lexi(struct parser_state *state)
bsearch(s_token, typenames, typename_top + 1,
sizeof(typenames[0]), strcmp_type))) {
state->keyword = 4; /* a type name */
- state->last_u_d = true;
+ if (state->last_token != period && state->last_token != unary_op)
+ state->last_u_d = true;
goto found_typename;
}
} else { /* we have a keyword */
--
2.50.1 (Apple Git-155)
From ccdde305aad8277bf91cf02577c723a008919288 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nathan@postgresql.org>
Date: Tue, 5 May 2026 16:04:14 -0500
Subject: [PATCH v1 2/2] run pgindent
---
src/backend/replication/logical/logicalfuncs.c | 2 +-
src/backend/storage/ipc/dsm_registry.c | 2 +-
src/bin/pg_basebackup/pg_basebackup.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/backend/replication/logical/logicalfuncs.c b/src/backend/replication/logical/logicalfuncs.c
index 512013b0ef0..71fbaf72269 100644
--- a/src/backend/replication/logical/logicalfuncs.c
+++ b/src/backend/replication/logical/logicalfuncs.c
@@ -218,7 +218,7 @@ pg_logical_slot_get_changes_guts(FunctionCallInfo fcinfo, bool confirm, bool bin
* what we need.
*/
if (!binary &&
- ctx->options.output_type !=OUTPUT_PLUGIN_TEXTUAL_OUTPUT)
+ ctx->options.output_type != OUTPUT_PLUGIN_TEXTUAL_OUTPUT)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("logical decoding output plugin \"%s\" produces binary output, but function \"%s\" expects textual data",
diff --git a/src/backend/storage/ipc/dsm_registry.c b/src/backend/storage/ipc/dsm_registry.c
index 2b56977659b..b9961c26019 100644
--- a/src/backend/storage/ipc/dsm_registry.c
+++ b/src/backend/storage/ipc/dsm_registry.c
@@ -479,7 +479,7 @@ pg_get_dsm_registry_allocations(PG_FUNCTION_ARGS)
entry->dsa.handle != DSA_HANDLE_INVALID)
vals[2] = Int64GetDatum(dsa_get_total_size_from_handle(entry->dsa.handle));
else if (entry->type == DSMR_ENTRY_TYPE_DSH &&
- entry->dsh.dsa_handle !=DSA_HANDLE_INVALID)
+ entry->dsh.dsa_handle != DSA_HANDLE_INVALID)
vals[2] = Int64GetDatum(dsa_get_total_size_from_handle(entry->dsh.dsa_handle));
else
nulls[2] = true;
diff --git a/src/bin/pg_basebackup/pg_basebackup.c b/src/bin/pg_basebackup/pg_basebackup.c
index c1a4672aa6f..80dc3bbc8da 100644
--- a/src/bin/pg_basebackup/pg_basebackup.c
+++ b/src/bin/pg_basebackup/pg_basebackup.c
@@ -1282,7 +1282,7 @@ ReceiveArchiveStream(PGconn *conn, pg_compress_specification *compress)
ReceiveCopyData(conn, ReceiveArchiveStreamChunk, &state);
/* If we wrote the backup manifest to a file, close the file. */
- if (state.manifest_file !=NULL)
+ if (state.manifest_file != NULL)
{
fclose(state.manifest_file);
state.manifest_file = NULL;
@@ -1341,7 +1341,7 @@ ReceiveArchiveStreamChunk(size_t r, char *copybuf, void *callback_data)
/* Sanity check. */
if (state->manifest_buffer != NULL ||
- state->manifest_file !=NULL)
+ state->manifest_file != NULL)
pg_fatal("archives must precede manifest");
/* Parse the rest of the CopyData message. */
@@ -1406,7 +1406,7 @@ ReceiveArchiveStreamChunk(size_t r, char *copybuf, void *callback_data)
appendPQExpBuffer(state->manifest_buffer, copybuf + 1,
r - 1);
}
- else if (state->manifest_file !=NULL)
+ else if (state->manifest_file != NULL)
{
/* Manifest data, write to disk. */
if (fwrite(copybuf + 1, r - 1, 1,
--
2.50.1 (Apple Git-155)
Attachments:
[text/plain] v1-0001-pgindent-Fix-spacing-after-when-member-name-match.patch (2.0K, ../../afplW8DvRONDc1yl@nathan/2-v1-0001-pgindent-Fix-spacing-after-when-member-name-match.patch)
download | inline diff:
From 804bb1097a44cc35178f3e1de46d17422ce7b67f Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nathan@postgresql.org>
Date: Tue, 5 May 2026 16:03:13 -0500
Subject: [PATCH v1 1/2] pgindent: Fix spacing after != when member name
matches typedef.
When a struct member name matches a registered typedef, pgindent
removes the space after "!=" (and some other operators):
entry->dsh.dsa_handle !=DSA_HANDLE_INVALID
In lexi.c, when an identifier matches the typedef list, the code
sets last_u_d = true before jumping to found_typename. This flag
tells the lexer that the next operator should be treated as unary,
which is correct for type names (e.g., "Datum *x" needs * to be
unary, not multiplication).
However, found_typename has a guard that recognizes when a typedef
name appears after "." or "->": in that case, the name is a struct
member, not a type, so it's returned as a plain identifier. The
problem is that last_u_d has already been set to true and is never
corrected. This causes the next operator (e.g., "!=") to be
misclassified as unary, which suppresses the space after it.
To fix, only set last_u_d when the token won't be caught by the
guard, i.e., when it will actually be treated as a type name.
This also explains why "==" was not affected: the "==" case always
returns binary_op regardless of last_u_d, while "!=" checks
last_u_d to decide.
---
src/tools/pg_bsd_indent/lexi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/tools/pg_bsd_indent/lexi.c b/src/tools/pg_bsd_indent/lexi.c
index 943bf7ce6b0..e846188d6f4 100644
--- a/src/tools/pg_bsd_indent/lexi.c
+++ b/src/tools/pg_bsd_indent/lexi.c
@@ -363,7 +363,8 @@ lexi(struct parser_state *state)
bsearch(s_token, typenames, typename_top + 1,
sizeof(typenames[0]), strcmp_type))) {
state->keyword = 4; /* a type name */
- state->last_u_d = true;
+ if (state->last_token != period && state->last_token != unary_op)
+ state->last_u_d = true;
goto found_typename;
}
} else { /* we have a keyword */
--
2.50.1 (Apple Git-155)
[text/plain] v1-0002-run-pgindent.patch (3.0K, ../../afplW8DvRONDc1yl@nathan/3-v1-0002-run-pgindent.patch)
download | inline diff:
From ccdde305aad8277bf91cf02577c723a008919288 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nathan@postgresql.org>
Date: Tue, 5 May 2026 16:04:14 -0500
Subject: [PATCH v1 2/2] run pgindent
---
src/backend/replication/logical/logicalfuncs.c | 2 +-
src/backend/storage/ipc/dsm_registry.c | 2 +-
src/bin/pg_basebackup/pg_basebackup.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/backend/replication/logical/logicalfuncs.c b/src/backend/replication/logical/logicalfuncs.c
index 512013b0ef0..71fbaf72269 100644
--- a/src/backend/replication/logical/logicalfuncs.c
+++ b/src/backend/replication/logical/logicalfuncs.c
@@ -218,7 +218,7 @@ pg_logical_slot_get_changes_guts(FunctionCallInfo fcinfo, bool confirm, bool bin
* what we need.
*/
if (!binary &&
- ctx->options.output_type !=OUTPUT_PLUGIN_TEXTUAL_OUTPUT)
+ ctx->options.output_type != OUTPUT_PLUGIN_TEXTUAL_OUTPUT)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("logical decoding output plugin \"%s\" produces binary output, but function \"%s\" expects textual data",
diff --git a/src/backend/storage/ipc/dsm_registry.c b/src/backend/storage/ipc/dsm_registry.c
index 2b56977659b..b9961c26019 100644
--- a/src/backend/storage/ipc/dsm_registry.c
+++ b/src/backend/storage/ipc/dsm_registry.c
@@ -479,7 +479,7 @@ pg_get_dsm_registry_allocations(PG_FUNCTION_ARGS)
entry->dsa.handle != DSA_HANDLE_INVALID)
vals[2] = Int64GetDatum(dsa_get_total_size_from_handle(entry->dsa.handle));
else if (entry->type == DSMR_ENTRY_TYPE_DSH &&
- entry->dsh.dsa_handle !=DSA_HANDLE_INVALID)
+ entry->dsh.dsa_handle != DSA_HANDLE_INVALID)
vals[2] = Int64GetDatum(dsa_get_total_size_from_handle(entry->dsh.dsa_handle));
else
nulls[2] = true;
diff --git a/src/bin/pg_basebackup/pg_basebackup.c b/src/bin/pg_basebackup/pg_basebackup.c
index c1a4672aa6f..80dc3bbc8da 100644
--- a/src/bin/pg_basebackup/pg_basebackup.c
+++ b/src/bin/pg_basebackup/pg_basebackup.c
@@ -1282,7 +1282,7 @@ ReceiveArchiveStream(PGconn *conn, pg_compress_specification *compress)
ReceiveCopyData(conn, ReceiveArchiveStreamChunk, &state);
/* If we wrote the backup manifest to a file, close the file. */
- if (state.manifest_file !=NULL)
+ if (state.manifest_file != NULL)
{
fclose(state.manifest_file);
state.manifest_file = NULL;
@@ -1341,7 +1341,7 @@ ReceiveArchiveStreamChunk(size_t r, char *copybuf, void *callback_data)
/* Sanity check. */
if (state->manifest_buffer != NULL ||
- state->manifest_file !=NULL)
+ state->manifest_file != NULL)
pg_fatal("archives must precede manifest");
/* Parse the rest of the CopyData message. */
@@ -1406,7 +1406,7 @@ ReceiveArchiveStreamChunk(size_t r, char *copybuf, void *callback_data)
appendPQExpBuffer(state->manifest_buffer, copybuf + 1,
r - 1);
}
- else if (state->manifest_file !=NULL)
+ else if (state->manifest_file != NULL)
{
/* Manifest data, write to disk. */
if (fwrite(copybuf + 1, r - 1, 1,
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-06 01:29 Chao Li <li.evan.chao@gmail.com>
parent: Nathan Bossart <nathandbossart@gmail.com>
1 sibling, 0 replies; 22+ messages in thread
From: Chao Li @ 2026-05-06 01:29 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
> On May 6, 2026, at 05:47, Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Tue, Dec 02, 2025 at 05:51:15PM -0500, Tom Lane wrote:
>> Chao Li <li.evan.chao@gmail.com> writes:
>>> On Dec 3, 2025, at 06:00, Nathan Bossart <nathandbossart@gmail.com> wrote:
>>>> I tried to fix pgindent for a few, but the code is basically impenetrable.
>>>> I didn't find any fixes upstream [0], either. As noted above, we could
>>>> also fix it by avoiding the naming conflicts. However, I can't imagine
>>>> that's worth the churn, and I've already spent way too much time on this,
>>>> so IMHO the best thing to do here is nothing.
>>
>>> I think that’s fine.
>>
>> Agreed, not worth the trouble to fool with.
>
> For fun, I spent some time with an AI tool to develop the attached fix for
> this problem. The explanation seems reasonable to me, although I am by no
> means a pgindent expert. When I looked at this in December, I did find
> this similar commit from upstream [0], but I failed to make the connection
> with last_u_d. 0002 is the result of a pgindent run after applying 0001.
> You'll notice that it fixes the exact set of cases I found with grep
> upthread.
>
> [0] https://github.com/pstef/freebsd_indent/commit/afa2239
>
> --
> nathan
> <v1-0001-pgindent-Fix-spacing-after-when-member-name-match.patch><v1-0002-run-pgindent.patch>
From 0002, the fix looks good. I tried to run the patched pgindent against all .c and .h files under src/ and contrib/, the result is exactly the same as 0002.
So, maybe worthy pushing before Tom running the annual pgindent.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-06 03:43 Tom Lane <tgl@sss.pgh.pa.us>
parent: Nathan Bossart <nathandbossart@gmail.com>
1 sibling, 1 reply; 22+ messages in thread
From: Tom Lane @ 2026-05-06 03:43 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Nathan Bossart <nathandbossart@gmail.com> writes:
> For fun, I spent some time with an AI tool to develop the attached fix for
> this problem. The explanation seems reasonable to me, although I am by no
> means a pgindent expert. When I looked at this in December, I did find
> this similar commit from upstream [0], but I failed to make the connection
> with last_u_d. 0002 is the result of a pgindent run after applying 0001.
> You'll notice that it fixes the exact set of cases I found with grep
> upthread.
Those changes are clearly improvements. I'm too tired to investigate
right now, but I wonder if we should adopt the upstream fix you
mention? (Or more generally, other changes they made since we forked?)
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-06 14:44 Nathan Bossart <nathandbossart@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 22+ messages in thread
From: Nathan Bossart @ 2026-05-06 14:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, May 05, 2026 at 11:43:39PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> For fun, I spent some time with an AI tool to develop the attached fix for
>> this problem. The explanation seems reasonable to me, although I am by no
>> means a pgindent expert. When I looked at this in December, I did find
>> this similar commit from upstream [0], but I failed to make the connection
>> with last_u_d. 0002 is the result of a pgindent run after applying 0001.
>> You'll notice that it fixes the exact set of cases I found with grep
>> upthread.
>
> Those changes are clearly improvements. I'm too tired to investigate
> right now, but I wonder if we should adopt the upstream fix you
> mention? (Or more generally, other changes they made since we forked?)
The upstream fix is from before we forked, it just didn't fix this
particular case. I don't see any missing changes from
pstef/freebsd_indent, but there have been a number of changes in the
FreeBSD version:
https://cgit.freebsd.org/src/log/usr.bin/indent
Some of our changes to pg_bsd_indent bumped INDENT_VERSION. Should we do
that here?
--
nathan
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-06 15:02 Tom Lane <tgl@sss.pgh.pa.us>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Tom Lane @ 2026-05-06 15:02 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Nathan Bossart <nathandbossart@gmail.com> writes:
> Some of our changes to pg_bsd_indent bumped INDENT_VERSION. Should we do
> that here?
We already have an INDENT_VERSION bump queued for the
space-between-comma-and-period change. I don't think we need two
bumps in this cycle, as long as we coordinate pushing these changes.
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-06 15:15 Nathan Bossart <nathandbossart@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 22+ messages in thread
From: Nathan Bossart @ 2026-05-06 15:15 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Wed, May 06, 2026 at 11:02:35AM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> Some of our changes to pg_bsd_indent bumped INDENT_VERSION. Should we do
>> that here?
>
> We already have an INDENT_VERSION bump queued for the
> space-between-comma-and-period change. I don't think we need two
> bumps in this cycle, as long as we coordinate pushing these changes.
Okay. I'll go ahead and commit the patches for $subject then, leaving out
the version bump.
--
nathan
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-06 15:17 Tom Lane <tgl@sss.pgh.pa.us>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Tom Lane @ 2026-05-06 15:17 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Wed, May 06, 2026 at 11:02:35AM -0400, Tom Lane wrote:
>> We already have an INDENT_VERSION bump queued for the
>> space-between-comma-and-period change. I don't think we need two
>> bumps in this cycle, as long as we coordinate pushing these changes.
> Okay. I'll go ahead and commit the patches for $subject then, leaving out
> the version bump.
No, *don't* do it right now. You'll break anyone using the
in-tree version, or if you also commit the ensuing code changes,
you'll break anyone using an out-of-tree copy. This stuff all
needs to go in at once.
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-06 15:20 Nathan Bossart <nathandbossart@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 22+ messages in thread
From: Nathan Bossart @ 2026-05-06 15:20 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Wed, May 06, 2026 at 11:17:17AM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> On Wed, May 06, 2026 at 11:02:35AM -0400, Tom Lane wrote:
>>> We already have an INDENT_VERSION bump queued for the
>>> space-between-comma-and-period change. I don't think we need two
>>> bumps in this cycle, as long as we coordinate pushing these changes.
>
>> Okay. I'll go ahead and commit the patches for $subject then, leaving out
>> the version bump.
>
> No, *don't* do it right now. You'll break anyone using the
> in-tree version, or if you also commit the ensuing code changes,
> you'll break anyone using an out-of-tree copy. This stuff all
> needs to go in at once.
Alright. I'll just prepare the patches and post them here for when that
time comes, then.
--
nathan
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-06 16:13 Nathan Bossart <nathandbossart@gmail.com>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Nathan Bossart @ 2026-05-06 16:13 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Wed, May 06, 2026 at 10:20:26AM -0500, Nathan Bossart wrote:
> Alright. I'll just prepare the patches and post them here for when that
> time comes, then.
Here's a new version of 0001 with a cleaned-up commit message. I've
omitted 0002, since it's just the result of running pgindent after apply
the first one.
--
nathan
From ca254e2440bdf5aeaf0574d133f35dab10d6b570 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nathan@postgresql.org>
Date: Wed, 6 May 2026 11:02:22 -0500
Subject: [PATCH v2 1/1] pgindent: Fix spacing after != when member name
matches typedef.
When a struct member name matches a registered typedef, pgindent
removes the space after "!=" (and some other operators), like so:
entry->dsh.dsa_handle !=DSA_HANDLE_INVALID
The problem is that the related code in lexi.c sets last_u_d to
true before jumping to found_typename, causing the next operator to
be classified as unary and suppressing the following space. This
is correct for type names, but not for struct members. For
example, "Datum *x" needs "*" to be unary to suppress the space
before "x". To fix, only set last_u_d before jumping to
found_typename if the typedef name doesn't appear after "." or
"->".
Note that this does not bump INDENT_VERSION. We'll do that just
once after some other changes to pg_bsd_indent are committed.
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/aS9hkwnkWf3dZIA_%40nathan
---
src/tools/pg_bsd_indent/lexi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/tools/pg_bsd_indent/lexi.c b/src/tools/pg_bsd_indent/lexi.c
index 943bf7ce6b0..e846188d6f4 100644
--- a/src/tools/pg_bsd_indent/lexi.c
+++ b/src/tools/pg_bsd_indent/lexi.c
@@ -363,7 +363,8 @@ lexi(struct parser_state *state)
bsearch(s_token, typenames, typename_top + 1,
sizeof(typenames[0]), strcmp_type))) {
state->keyword = 4; /* a type name */
- state->last_u_d = true;
+ if (state->last_token != period && state->last_token != unary_op)
+ state->last_u_d = true;
goto found_typename;
}
} else { /* we have a keyword */
--
2.50.1 (Apple Git-155)
Attachments:
[text/plain] v2-0001-pgindent-Fix-spacing-after-when-member-name-match.patch (1.8K, ../../aftooa3UABE3AuZf@nathan/2-v2-0001-pgindent-Fix-spacing-after-when-member-name-match.patch)
download | inline diff:
From ca254e2440bdf5aeaf0574d133f35dab10d6b570 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nathan@postgresql.org>
Date: Wed, 6 May 2026 11:02:22 -0500
Subject: [PATCH v2 1/1] pgindent: Fix spacing after != when member name
matches typedef.
When a struct member name matches a registered typedef, pgindent
removes the space after "!=" (and some other operators), like so:
entry->dsh.dsa_handle !=DSA_HANDLE_INVALID
The problem is that the related code in lexi.c sets last_u_d to
true before jumping to found_typename, causing the next operator to
be classified as unary and suppressing the following space. This
is correct for type names, but not for struct members. For
example, "Datum *x" needs "*" to be unary to suppress the space
before "x". To fix, only set last_u_d before jumping to
found_typename if the typedef name doesn't appear after "." or
"->".
Note that this does not bump INDENT_VERSION. We'll do that just
once after some other changes to pg_bsd_indent are committed.
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/aS9hkwnkWf3dZIA_%40nathan
---
src/tools/pg_bsd_indent/lexi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/tools/pg_bsd_indent/lexi.c b/src/tools/pg_bsd_indent/lexi.c
index 943bf7ce6b0..e846188d6f4 100644
--- a/src/tools/pg_bsd_indent/lexi.c
+++ b/src/tools/pg_bsd_indent/lexi.c
@@ -363,7 +363,8 @@ lexi(struct parser_state *state)
bsearch(s_token, typenames, typename_top + 1,
sizeof(typenames[0]), strcmp_type))) {
state->keyword = 4; /* a type name */
- state->last_u_d = true;
+ if (state->last_token != period && state->last_token != unary_op)
+ state->last_u_d = true;
goto found_typename;
}
} else { /* we have a keyword */
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-12 21:33 Tom Lane <tgl@sss.pgh.pa.us>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Tom Lane @ 2026-05-12 21:33 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Nathan Bossart <nathandbossart@gmail.com> writes:
> Here's a new version of 0001 with a cleaned-up commit message. I've
> omitted 0002, since it's just the result of running pgindent after apply
> the first one.
I think we're about ready to roll on doing the pgindent run.
Do you want to push your patch tomorrow AM, and then I'll get
on with the rest?
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-12 22:09 Nathan Bossart <nathandbossart@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 22+ messages in thread
From: Nathan Bossart @ 2026-05-12 22:09 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, May 12, 2026 at 05:33:50PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> Here's a new version of 0001 with a cleaned-up commit message. I've
>> omitted 0002, since it's just the result of running pgindent after apply
>> the first one.
>
> I think we're about ready to roll on doing the pgindent run.
> Do you want to push your patch tomorrow AM, and then I'll get
> on with the rest?
Sounds good. We won't be back-patching any of this, right?
--
nathan
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-12 22:12 Tom Lane <tgl@sss.pgh.pa.us>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Tom Lane @ 2026-05-12 22:12 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Tue, May 12, 2026 at 05:33:50PM -0400, Tom Lane wrote:
>> I think we're about ready to roll on doing the pgindent run.
>> Do you want to push your patch tomorrow AM, and then I'll get
>> on with the rest?
> Sounds good. We won't be back-patching any of this, right?
Right, just HEAD.
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-13 14:12 Nathan Bossart <nathandbossart@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 22+ messages in thread
From: Nathan Bossart @ 2026-05-13 14:12 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, May 12, 2026 at 06:12:21PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> On Tue, May 12, 2026 at 05:33:50PM -0400, Tom Lane wrote:
>>> I think we're about ready to roll on doing the pgindent run.
>>> Do you want to push your patch tomorrow AM, and then I'll get
>>> on with the rest?
>
>> Sounds good. We won't be back-patching any of this, right?
>
> Right, just HEAD.
Committed.
--
nathan
^ permalink raw reply [nested|flat] 22+ messages in thread
* Re: pgindent versus struct members and typedefs
@ 2026-05-13 14:13 Tom Lane <tgl@sss.pgh.pa.us>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 0 replies; 22+ messages in thread
From: Tom Lane @ 2026-05-13 14:13 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Chao Li <li.evan.chao@gmail.com>; Rahila Syed <rahilasyed90@gmail.com>; Robert Haas <robertmhaas@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Nathan Bossart <nathandbossart@gmail.com> writes:
> Committed.
Thanks, I'll start on the rest.
regards, tom lane
^ permalink raw reply [nested|flat] 22+ messages in thread
end of thread, other threads:[~2026-05-13 14:13 UTC | newest]
Thread overview: 22+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-12-02 22:00 pgindent versus struct members and typedefs Nathan Bossart <nathandbossart@gmail.com>
2025-12-02 22:46 ` Chao Li <li.evan.chao@gmail.com>
2025-12-02 22:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-12-02 23:06 ` Chao Li <li.evan.chao@gmail.com>
2025-12-02 23:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-12-02 23:31 ` Chao Li <li.evan.chao@gmail.com>
2025-12-03 15:35 ` Andrew Dunstan <andrew@dunslane.net>
2025-12-03 17:25 ` Álvaro Herrera <alvherre@kurilemu.de>
2026-05-05 21:47 ` Nathan Bossart <nathandbossart@gmail.com>
2026-05-06 01:29 ` Chao Li <li.evan.chao@gmail.com>
2026-05-06 03:43 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-05-06 14:44 ` Nathan Bossart <nathandbossart@gmail.com>
2026-05-06 15:02 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-05-06 15:15 ` Nathan Bossart <nathandbossart@gmail.com>
2026-05-06 15:17 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-05-06 15:20 ` Nathan Bossart <nathandbossart@gmail.com>
2026-05-06 16:13 ` Nathan Bossart <nathandbossart@gmail.com>
2026-05-12 21:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-05-12 22:09 ` Nathan Bossart <nathandbossart@gmail.com>
2026-05-12 22:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-05-13 14:12 ` Nathan Bossart <nathandbossart@gmail.com>
2026-05-13 14:13 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox