pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Julien Rouhaud <rjuju123@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Christoph Berg <myon@debian.org>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: compute_query_id and pg_stat_statements
Date: Wed, 12 May 2021 17:30:26 +0800
Message-ID: <20210512093026.ur43cu3c46eshbew@nol> (raw)
In-Reply-To: <CAFj8pRDtehwqY9JgQsRBakpqsd9UfcsKxxF4u3TVpgBzrtib0g@mail.gmail.com>
References: <20210512.110836.2162399537656469720.horikyota.ntt@gmail.com>
	<20210512024201.ak3ofofakn2ymhiv@nol>
	<20210512.143335.1053382893089496881.horikyota.ntt@gmail.com>
	<CAFj8pRB0isJLNBcom3czQCC3g7S6ZFc59jdPfps00r8j=dVZbg@mail.gmail.com>
	<20210512061049.dykngnivdoesquxb@nol>
	<CAFj8pRBiBsReXskjmU6c-+HHS2Q5=7eB9JJJDXvVbUZnR+FmFA@mail.gmail.com>
	<20210512071339.hl2wrf7gfuvjnbm4@nol>
	<CAFj8pRCWjQtw6A8t335P0soehc0ypjCz38aoASRbP7diWmQmtg@mail.gmail.com>
	<20210512081445.axosz3xf7ydrhe7o@nol>
	<CAFj8pRDtehwqY9JgQsRBakpqsd9UfcsKxxF4u3TVpgBzrtib0g@mail.gmail.com>

On Wed, May 12, 2021 at 10:57:25AM +0200, Pavel Stehule wrote:
> 
> My second proposal can work for your example too. pg_stat_statements have
> to require any active queryid computing. And when it is not available, then
> the exception should be raised.
> 
> The custom queryid can return null, and still the queryid will be computed.
> Maybe the warning can be enough. Just, if somebody use pg_stat_statements
> function, then enforce the check if queryid is computed (compute_query_id
> is true || some hook is not null), and if not then raise a warning.

Ah I'm sorry I misunderstood your proposal.  Yes, definitely adding a warning
or an error when executing pg_stat_statements() SRF would help, that's a great
idea!

I'll wait a bit in case someone has any objection, and if not send an updated
patch!





view thread (158+ messages)  latest in thread

Message-ID: <20210512093026.ur43cu3c46eshbew@nol>
Permalink:  ../20210512093026.ur43cu3c46eshbew@nol/
Also on:    postgresql.org/message-id/20210512093026.ur43cu3c46eshbew@nol

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: rjuju123@gmail.com, pavel.stehule@gmail.com, horikyota.ntt@gmail.com, magnus@hagander.net, masao.fujii@oss.nttdata.com, michael@paquier.xyz, andres@anarazel.de, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, sfrost@snowman.net, bruce@momjian.us, myon@debian.org, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: compute_query_id and pg_stat_statements
  In-Reply-To: <20210512093026.ur43cu3c46eshbew@nol>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox