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
