Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements - Mailing list pgsql-hackers

From Andrei Zubkov
Subject Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Date
Msg-id e9b968e115e7683a3cac114ec88af3a0eb9a0261.camel@moonset.ru
Whole thread Raw
In response to Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi Michael,

Thank you for your attention.

On Thu, 2023-03-16 at 16:13 +0900, Michael Paquier wrote:
> +/* First we have to remove them from the extension */
> +ALTER EXTENSION pg_stat_statements DROP VIEW pg_stat_statements;
> +ALTER EXTENSION pg_stat_statements DROP FUNCTION
> pg_stat_statements(boolean);
> +ALTER EXTENSION pg_stat_statements DROP FUNCTION
> +  pg_stat_statements_reset(Oid, Oid, bigint);
> 
> The upgrade script of an extension is launched by the backend in the
> context of an extension, so these three queries should not be needed,
> as far as I recall.

Agreed. I've done it as it was in previous versions. But I'm sure those
are unnecessary.

> Wouldn't it be better to do this kind of refactoring in its own patch
> to make the follow-up changes more readable?  This function is
> changed
> to return a timestamp rather than void, but IS NOT NULL applied on
> the
> existing queries would also return true.  This would clean up quite a
> few diffs in the main patch..
Splitting this commit seems reasonable to me.

New version is attached.

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: logical decoding and replication of sequences, take 2
Next
From: Yuya Watari
Date:
Subject: Re: Making empty Bitmapsets always be NULL