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

From Imseih (AWS), Sami
Subject Re: [BUG] pg_stat_statements and extended query protocol
Date
Msg-id 8FFCD4F0-8B04-4EA2-9190-FEC70C376523@amazon.com
Whole thread Raw
In response to Re: [BUG] pg_stat_statements and extended query protocol  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [BUG] pg_stat_statements and extended query protocol
List pgsql-hackers
> How does JDBC test that? Does it have a dependency on
> pg_stat_statements?

No, at the start of the thread, a sample jdbc script was attached.
But I agree, we need to add test coverage. See below.


>> 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/?

Yes, that is possible but we will need to add a libpq API
that allows the caller to pass in a "fetch size".
PQsendQueryParams does not take in a "fetch size", 
so it returns all rows, through PQsendQueryParams

https://github.com/postgres/postgres/blob/master/src/interfaces/libpq/fe-exec.c#L1882

Adding such an API that takes in a "fetch size" will be beneficial 
not just for this test, but I can see it enabling another psql meta command,
similar to \bind but that takes in a "fetch size".

Regards

--
Sami Imseih
Amazon Web Services (AWS)




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Dropped and generated columns might cause wrong data on subs when REPLICA IDENTITY FULL
Next
From: Peter Eisentraut
Date:
Subject: Re: Transparent column encryption