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/[email protected]
[1]
https://postgr.es/m/ca+qey+aasyk6wvbw4qyzhz4bahhycday_q5ecmhkev_eb9c...@mail.gmail.com
[2]
https://postgr.es/m/cab-jlwbbfnuasyenzwp0tck9unkthbzqi6woxnevut6+mv8...@mail.gmail.com
[3] https://postgr.es/m/[email protected]