Re: Fix typos and inconsistencies for v16

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix typos and inconsistencies for v16
Date: 2023-04-18 01:35:00
Message-ID: CAApHDvpNfPVDpy6KVhGjTwLwx3dhYEOmLOyvbDu6vSkZEXCPMw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 18 Apr 2023 at 06:00, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> Please consider fixing the following unique words/identifiers introduced in v16:

Thanks, I've pushed all of these apart from the following 2.

> 45. tar_set_error -- remove (obsolete since ebfb814f7)
> 46. test_tranche_name -- remove (not used, see 006b69fd9)

These didn't quite fit in with the "typo fixes" category of the
commit, so I left them off the commit I just pushed.

> Also, maybe OID_MAX should be removed from src/include/postgres_ext.h as it's unused since eb8312a22.

I didn't touch this. It seems like it could be useful for extensions
and client apps even if it's not used in core.

> Beside that, this simple script:
> for w in $(cat src/tools/pgindent/typedefs.list); do grep -q -P "\b$w\b" -r * --exclude typedefs.list || echo "$w"; done
> detects 58 identifiers that don't exist in the source tree anymore (see typedefs.lost attached).
> Maybe they should be removed from typedefs.list too.

I didn't touch this either. typedefs.list normally gets some work
done during the pgindent run, which is likely going to happen around
May or June. Maybe you can check back after that's done and make sure
all these unused ones were removed. I'm not sure if the process that's
done for that only finds new ones that are now required or if it
completely generates a new list.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2023-04-18 01:40:51 RE: pg_upgrade and logical replication
Previous Message Amin 2023-04-18 01:03:08 Re: Scans are offloaded to SeqScan instead of CustomScan when there are multiple relations in the same query