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 <robertmh...@gmail.com> wrote: > > On Wed, Jun 20, 2018 at 10:19 AM, Euler Taveira <eu...@timbira.com.br> wrote: >> 2018-06-20 4:30 GMT-03:00 Haribabu Kommi <kommi.harib...@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 >
