Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring

Hi hackers,

This discussion prompted me to ask an LLM to review the catalog changes
between PostgreSQL 18 and 19 for similar API naming issues. I mostly agree
with the following findings.

1. pg_stat_get_stat_reset_time() (a5b543258aa, [0])

This returns the reset time for a relation. Maybe
pg_stat_get_relation_stat_reset_time(), following the naming pattern
of pg_stat_get_db_stat_reset_time() and
pg_stat_get_function_stat_reset_time().

The original proposal mentions the C macro as a naming constraint,
but proname can differ from prosrc.

2. pg_get_multixact_stats() (97b101776ce, this thread [1])

I like pg_get_multixact_usage(). There is also a documentation mismatch:
num_mxids is documented as integer, but pg_proc.dat declares it as
bigint. I'd fix the documentation along with the rename.

Next two seem less important, less user-facing.

3. pg_get_publication_tables() (fd7a25af11e, [2])

Adding the targeted overload also renamed the existing variadic
argument from pubname to pubnames. That changes named-argument
resolution for calls such as:

SELECT * FROM pg_get_publication_tables(
VARIADIC pubname => ARRAY[]::text[]);

This is an undocumented helper, and I don't know of affected callers,
but I'd keep pubname on the old overload. The new overload can use
pubnames without changing the existing interface.

4. pg_range.rngmltconstruct2 (c257ba83971, [3])

This triggered LLM because documentation calls it the "2-argument multirange
constructor". But I think it's fine. I just left it here for completeness.

Do these changes seem worth attention during this hot release?

Thank you!

Best regards, Andrey Borodin.

[0] https://postgr.es/m/aN8l182jKxEq1h9f@paquier.xyz
[1] https://postgr.es/m/CA+QeY+AAsYK6WvBW4qYzHz4bahHycDAY_q5ECmHkEV_eB9ckzg@mail.gmail.com
[2] https://postgr.es/m/CAB-JLwbBFNuASyEnZWP0Tck9uNkthBZqi6WoXNevUT6+mV8XmA@mail.gmail.com
[3] https://postgr.es/m/7d63ddfa-c735-4dfe-8c7a-4f1e2a621058@eisentraut.org