Why not just parameterize it with the three key fields; userid, dbid, and queryid?
i.e It would then allow it be limited to only records associated with a given user and/or database as well.
pg_stat_statements_reset(dbid oid, userid oid, queryid bigint)
pg_stat_statements_reset(null, null, 3569076157) — all for a given query
pg_stat_statements_reset(6384, null, 3569076157)
pg_stat_statements_reset(null, 16429, 3569076157)
pg_stat_statements_reset(6384, 6384, 3569076157)
pg_stat_statements_reset(6384, null, null) — all for a given database.
.
.
.
>> pg_stat_statements_reset()
> On Jun 22, 2018, at 11:06 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Jun 20, 2018 at 10:19 AM, Euler Taveira <euler@timbira.com.br> wrote:
>> 2018-06-20 4:30 GMT-03:00 Haribabu Kommi <kommi.haribabu@gmail.com>:
>>> Attached is a simple patch with implementation. Comments?
>>>
>> Why don't you extend the existing function pg_stat_statements_reset()?
>
> Well, the existing function doesn't take any arguments. We could add
> an additional version of it that takes an argument, or we could
> replace the existing version with one that has an optional argument.
> But are either of those things any better than just adding a new
> function with a different name, like
> pg_stat_statements_reset_statement()?
>
> I have not had such good experiences with function overloading, either
> in PostgreSQL or elsewhere, that I'm ready to say reusing the same
> name is definitely the right approach. For example, suppose we
> eventually end up with a function that resets all the statements, a
> function that resets just one statement, a function that resets all
> statements for one user, and a function that resets all statements
> where the statement text matches a certain regexp. If those all have
> separate names, everything is fine. If they all have the same name,
> there's no way that's not confusing.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>