Re: [survey] New "Stable" QueryId based on normalized query text

On Wed, Mar 20, 2019 at 03:19:58PM -0700, legrand legrand wrote:
> > The rest of thread raise quite a lot of concerns about the semantics,
> > the cost and the correctness of this patch. After 5 minutes checking,
> > it wouldn't suits your need if you use custom functions, custom types,
> > custom operators (say using intarray extension) or if your tables
> > don't have columns in the same order in every environment. And there
> > are probably other caveats that I didn't see;
>
> Yes I know,
> It would have to be extended at less at functions, types, operators ...
> names
> and a guc pg_stat_statements.queryid_based= 'names' (default being 'oids')
>
> and with a second guc ('fullyqualifed' ?)
> sould include tables, functions, types, operators ... namespaces
>
> let "users" specify their needs, we will see ;o)

Why can't we just explose the hash computation as an SQL function and
let people call it with pg_stat_activity.query or wherever they want the
value? We can install multiple functions if needed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +