Re: [BUG] pg_stat_statements and extended query protocol - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [BUG] pg_stat_statements and extended query protocol
Date
Msg-id ZBwaEbdpVYJPXjT5@paquier.xyz
Whole thread Raw
In response to Re: [BUG] pg_stat_statements and extended query protocol  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Responses Re: [BUG] pg_stat_statements and extended query protocol  ("Imseih (AWS), Sami" <simseih@amazon.com>)
List pgsql-hackers
On Thu, Mar 23, 2023 at 09:33:16AM +0100, Drouvot, Bertrand wrote:
> Thanks! LGTM and also do confirm that, with the patch, the JDBC test
> does show the correct results.

How does JDBC test that?  Does it have a dependency on
pg_stat_statements?
>
> That said, not having a test (for the reasons you explained
> up-thread) associated with the patch worry me a bit.

Same impression here.

> But, I'm tempted to say that adding new tests could be addressed
> separately though (as this patch looks pretty straightforward).

Even small patches can have gotchas.  I think that this should have
tests in-core rather than just depend on JDBC and hope for the best.
Even if \bind does not allow that, we could use an approach similar to
libpq_pipeline, for example, depending on pg_stat_statements for the
validation with a test module in src/test/modules/?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Should we remove vacuum_defer_cleanup_age?
Next
From: Peter Smith
Date:
Subject: Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)