pgindent run
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t44466psql -h localhost -U postgresBuilt from patchset v4 (message #4), July 27, 2026 at 04:39 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t44466_4 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t44466_4 && git checkout t44466_4Patchset v4 (message #4) is on t44466_4
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
Attachments:
pgindent-run-20210628.patchtext/x-patch; charset=UTF-8; name=pgindent-run-20210628.patchDownload+151-131
On Tue, 29 Jun 2021 at 00:29, Andrew Dunstan <andrew@dunslane.net> 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 the policy entry. */
if (num_roles > 0)
{
- /* This is the array for the new tuple */
- role_ids = construct_array(role_oids, num_roles, OIDOID,
- sizeof(Oid), true, TYPALIGN_INT);
+ /* This is the array for the new tuple */
+ role_ids = construct_array(role_oids, num_roles, OIDOID,
+ sizeof(Oid), true, TYPALIGN_INT);I wasn't too sure about the status of this one. Michael did mention it
in [1]/messages/by-id/YM0puvBnbBIZxJt2@paquier.xyz, 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 that whole function in a little bit".
David
On 6/28/21 8:52 AM, David Rowley wrote:
On Tue, 29 Jun 2021 at 00:29, Andrew Dunstan <andrew@dunslane.net> 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 the policy entry. */ if (num_roles > 0) { - /* This is the array for the new tuple */ - role_ids = construct_array(role_oids, num_roles, OIDOID, - sizeof(Oid), true, TYPALIGN_INT); + /* This is the array for the new tuple */ + role_ids = construct_array(role_oids, num_roles, OIDOID, + sizeof(Oid), true, TYPALIGN_INT);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 that whole function in a little bit".David
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.
Unfortunately, while pgindent has code that allows protecting comments
from being formatted, it doesn't have a similar mechanism for code AFAICT.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> 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 that whole function in a little bit".
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]/messages/by-id/1573181.1624220108@sss.pgh.pa.us committed, and then this issue will go away.
regards, tom lane
I wrote:
Andrew Dunstan <andrew@dunslane.net> 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 will go away.
Wait ... I did already, at 5a0f1c8c0. Are you sure you were indenting
current HEAD?
regards, tom lane
On 6/28/21 10:44 AM, Tom Lane wrote:
I wrote:
Andrew Dunstan <andrew@dunslane.net> 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 will go away.Wait ... I did already, at 5a0f1c8c0. Are you sure you were indenting
current HEAD?
No, see revised patch. I posted at 10.13
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com