Re: run pgindent on a regular basis / scripted manner

On 2023-02-07 Tu 10:25, Justin Pryzby wrote:
> On Sat, Feb 04, 2023 at 12:37:11PM -0500, Tom Lane wrote:
>> Justin Pryzby<pryzby(at)telsasoft(dot)com> writes:
>> Hmmm ... inserting all of those as the default options would likely
>> make it impossible to update pg_bsd_indent itself with anything like
>> its current indent style (not that it's terribly consistent about
>> that). I could see inventing a --postgresql shortcut switch perhaps.
> Or you could add ./.indent.pro, or ./src/tools/indent.profile for it to
> read.
>
>>> Would you want to make those the default options of the in-tree indent ?
>>> Or provide a shortcut like --postgresql ?
>> But it's not clear to me why you're allergic to the perl wrapper?
> My allergy is to the totality of the process, not to the perl component.
> It's a bit weird to enforce a coding style that no upstream indent tool
> supports. But what's weirder is that, *having forked the indent tool*,
> it still doesn't implement the desired style, and the perl wrapper tries
> to work around that.
>
> It would be more reasonable if the forked C program knew how to handle
> the stuff for which the perl script currently has kludges to munge the
> source code before indenting and then un-munging afterwards.
>
> Or if the indentation were handled by the (or a) perl script itself.
>
> Or if the perl script handled everything that an unpatched "ident"
> didn't handle, rather than some things but not others, demanding use of
> a patched indent as well as a perl wrapper (not just for looping around
> files and fancy high-level shortcuts like indenting staged files).
>
> On the one hand, "indent" ought to handle all the source-munging stuff.
> On the other hand, it'd be better to use an unpatched indent tool. The
> current way is the worst of both worlds.
>
> Currently, the perl wrapper supports the "/* -"-style comments that
> postgres wants to use (why?) by munging the source code. That could be
> supported in pg-bsd-indent with a one line change. I think an even
> better option would be to change postgres' C files to use "/*-" without
> a space, which requires neither perl munging nor patching indent.

Historically we used to do a heck of a lot more in pgindent that is
currently done in the pre_indent and post_indent functions. If you want
to spend time implementing that logic in pg_bsd_indent so we can remove
the remaining bits of that processing then go for it.

> On a less critical note, I wonder if it's a good idea to import
> pgbsdindent as a git "submodule".

Meh, git submodules can be a pain in the neck in my limited experience.
I'd rather steer clear.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com