Re: libpq - lack of support to set the fetch size - Mailing list pgsql-general

From matshyeq
Subject Re: libpq - lack of support to set the fetch size
Date
Msg-id CAONr5=vYNp1TbFN4hLHkni23gANcP-Fp=6699CMzAi7Ogk=96Q@mail.gmail.com
Whole thread Raw
In response to Re: libpq - lack of support to set the fetch size  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: libpq - lack of support to set the fetch size  (Marko Kreen <markokr@gmail.com>)
List pgsql-general

Marko, Tom, Adrian, Jeff, Daniel - thank you all for valuable feedback!


Two general questions:

- when using PQsetSingleRowMode() function - does it give an option to define how many rows to cache on client's side (like JDBC setFetchSize() does) or leaves it at pqlib's discretion?

- is it/would it be possible to add corresponding option to pgAdmin to limit initially (and each subsequently) returned rows in Query Tool by custom defined max value?


@Tom

>Perhaps you should actually experiment with that solution instead of rejecting it out of hand.  Or at least RTFM about it.

As I'm not using pqlib directly I'm unable to leverage PQsetSingleRowMode() call (or at least I'm not aware how to do this from DBD::Pg)

I simply passed you feedback given by them.


@Adrian

The example in the documentation you refer to actually demonstrates this has been properly implemented in JDBC.

By properly I mean call to:

setFetchSize()

works, whatever it actually does behind the scenes (cursors?) it doesn't actually require a developer to declare and utilize cursors explicitly, like

st.execute("DECLARE csr CURSOR FOR SELECT * FROM myBigTable;");

conn.prepareStatement("fetch 1000 from csr");


@Jeff

I'll make a suggestion to DBD::Pg development


@Daniel

Very interesting alternative. You're welcome to contribute to this stackoverflow question!

Does it mean $data is a reference to single returned row of data (`COPY formatted`)?


Kind Regards

Msciwoj


pgsql-general by date:

Previous
From: Torsten Förtsch
Date:
Subject: Re: How to make PG use work_mem?
Next
From: nill
Date:
Subject: Re: Extracting data from the view to retrieve the foreign key is not declared