Hi,
On 12/6/22 3:45 AM, Michael Paquier wrote:
> On Mon, Dec 05, 2022 at 05:16:56PM +0900, Michael Paquier wrote:
>> Doing that in a separate patch is fine by me.
>
> I have applied the patch for the tab entries, then could not resist
> poking at the parts for the db entries. This leads to more reduction
> than the other one actually, as of:
> 4 files changed, 169 insertions(+), 447 deletions(-)
>
> Like the previous one, the functions have the same names and the field
> names are updated to fit in the picture. Thoughts?
Thanks! For this one (the INT64 case) the fields renaming are not strictly mandatory as we could add the "n_" in the
macroitself, something like:
+#define PG_STAT_GET_DBENTRY_INT64(stat) \
+Datum
\
+CppConcat(pg_stat_get_db_,stat)(PG_FUNCTION_ARGS) \
+{
\
+ Oid dbid = PG_GETARG_OID(0); \
+ int64 result; \
+ PgStat_StatDBEntry *dbentry; \
+
\
+ if ((dbentry = pgstat_fetch_stat_dbentry(dbid)) == NULL) \
+ result = 0;
\
+ else
\
+ result = (int64) (dbentry->CppConcat(n_,stat)); \
+
\
+ PG_RETURN_INT64(result); \
+}
Fields renaming was mandatory in the previous ones as there was already a mix of with/without "n_" in the existing
fieldsnames.
That said, I think it's better to rename the fields as you did (to be "consistent" on the naming between relation/db
stats),so the patch LGTM.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
