Re: Add a statistics view to track usage of deprecated features

On Mon, Jun 29, 2026 at 11:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > On Mon, Jun 29, 2026 at 10:24:02AM +0900, Shinya Kato wrote:
> >> I would like to propose a patch that adds a new cumulative statistics
> >> view, pg_stat_deprecated_features, which tracks how often each
> >> deprecated feature is used across the cluster.
>
> > I am unconvinced that this is useful.
>
> I'm pretty down on it as well, because it presupposes that we have
> a well-defined set of deprecated features. We're not that well
> organized in that area, and probably never will be.

Thank you both for the quick feedback.

Michael's point about GLOBAL/LOCAL made me look at the deprecated
features one by one, and it corrected a wrong assumption on my side. I
had been treating everything marked deprecated as something that would
eventually be removed. In fact "deprecated" covers at least three
different cases:

1. deprecated and documented to be removed. MD5 passwords are the
clearest, with "deprecated and will be removed in a future release".
Some are softer, such as the txid_* functions ("still supported for
backward compatibility, but may be removed from a future release") and
the old geometric operator names <^ and >^ ("deprecated and will
eventually be removed").

2. deprecated but kept deliberately for backward compatibility with no
intent to remove, such as ALTER GROUP ("obsolete ... still accepted
for backwards compatibility").

3. deprecated but more likely to be reinterpreted than removed, which
is the GLOBAL/LOCAL case Michael describes. The CREATE TABLE docs say
PostgreSQL "might adopt a more standard-compliant interpretation of
their meaning".

Only the first case is what this view was meant for. The intent was to
let an administrator confirm, before a major-version upgrade, whether
their workload still relies on a feature that will be removed. Once it
is filtered down to features the documentation actually says will or
may be removed, though, the set is very small. It is essentially MD5,
plus a few softer or niche cases. Everything else I had listed falls
into the second or third case.

For a set that small, a dedicated cumulative statistics kind and a
standing view is out of proportion, which is Michael's point about not
spending a stats kind ID on this. So I would like to withdraw this
proposal.

--
Best regards,
Shinya Kato
NTT OSS Center