On 2025-10-31 04:03 +0100, David Rowley wrote:
> On Fri, 31 Oct 2025 at 13:53, Erik Wienhold <ewie@ewie.name> wrote:
> > But I also agree with Tom that keeping a consistent style is impossible
> > in the long run. But it also shows that the docs are still written by
> > humans. As long as we can keep a consistent style within a single
> > listing (or even an entire page) I'm satisfied as a reader.
>
> For me, I don't see this as a reason not to try. If we do get things
> to a consistent point, then anyone making changes that reference
> existing portions of the documentation for inspiration should maintain
> consistency. If we're entirely random, then there's no hope for anyone
> to figure out what the best practice or perfected casing is.
Sure. I didn't say we shouldn't try. But from my experience, minor
formatting issues slip through all the time if you can't rely on an
autoformatter or linter. Maybe less so in these docs because the sample
queries are usually short. But it already took me a couple of rounds to
find every lowercase keyword so far and I guess I still missed some.
> > Besides that I've fixed a couple of more places that had lowercase
> > keywords or were missing some whitespace that I had missed before.
>
> A couple of things.
>
> 1) I see you've added a space after "INSERT INTO table" and before the
> column list, but not consistently, per:
>
> git grep -E "INSERT INTO \w+\("
Fixed in the attached v4. Except for one match in dblink.sgml that is
the sample output of dblink_build_sql_insert which actually omits the
space after the table name and VALUES keyword.
> 2) An identifier casing has been changed here:
>
> -SELECT sub_part, SUM(quantity) as total_quantity
> +SELECT sub_part, sum(quantity) AS total_quantity
Reverted back to uppercase SUM. I think this was the only changed
identifier and what remains should only be keyword and whitespace
changes to keep the patch focused on that.
> You could also look at the results of the SQL command that's returned
> by the following SQL to see if there's anything else. I do see some
> "ROLLUP(", "EXISTS(", "GROUPING(" and "VALUES(" in there. You have
> been changing "VALUES(" to "VALUES (", so I assume those ones have
> been missed:
>
> select 'git grep -E "\b(' || string_agg(UPPER(word),'|') || ')\("'
> from pg_get_keywords();
Thanks. Fixed those as well. But only for keywords with non-C catcodes
because I figured that the catcode C keywords mostly cover builtin
function names where extra whitespace before the opening paren doesn't
make sense. Missed the uppercase keywords before because I was only
searching for the lowercase ones.
--
Erik Wienhold
