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@momjian.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 +