On 2011-11-03 17:26, Marko Kreen wrote:
On Mon, Oct 31, 2011 at 7:09 PM, Tom Lane wrote:
Can't you do that today with a multi-command string submitted to
PQsendQuery, followed by multiple calls to PQgetResult?
It's more annoying to to error handling on that, plus it still keeps the
blocking b
On Mon, Oct 31, 2011 at 7:09 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 31.10.2011 17:44, Mark Hills wrote:
>>> Could libpq be reasonably modified to allow this?
>
>> I believe it's doable in theory, no-one has just gotten around to it.
>> Patches are welcome.
>
> Can't you do that to
On 2011-11-01 00:53, Merlin Moncure wrote:
On Mon, Oct 31, 2011 at 12:49 PM, Mark Hills wrote:
Furthermore, in most apps it'd be a serious PITA to keep track of which
reply is for which query, so I doubt that such a feature is of general
usefulness.
In our UI case, we already have a queue.
Heikki Linnakangas writes:
> I think a common use for this would be doing multiple inserts or updates on
> one go. Like, insert into a parent table, then more details into child
> tables. You don't care about getting the results back in that case, as long
> as you get an error on failure.
As of 9
On Mon, Oct 31, 2011 at 1:08 PM, Merlin Moncure wrote:
> On Mon, Oct 31, 2011 at 12:49 PM, Merlin Moncure wrote:
>> On Mon, Oct 31, 2011 at 12:09 PM, Tom Lane wrote:
>>> Heikki Linnakangas writes:
On 31.10.2011 17:44, Mark Hills wrote:
> Could libpq be reasonably modified to allow this
On Mon, Oct 31, 2011 at 12:49 PM, Merlin Moncure wrote:
> On Mon, Oct 31, 2011 at 12:09 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> On 31.10.2011 17:44, Mark Hills wrote:
Could libpq be reasonably modified to allow this?
>>
>>> I believe it's doable in theory, no-one has just gott
On Mon, Oct 31, 2011 at 12:49 PM, Mark Hills wrote:
> On Mon, 31 Oct 2011, Tom Lane wrote:
>
>> Heikki Linnakangas writes:
>> > On 31.10.2011 17:44, Mark Hills wrote:
>> >> Could libpq be reasonably modified to allow this?
>>
>> > I believe it's doable in theory, no-one has just gotten around to
On Mon, 31 Oct 2011, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 31.10.2011 17:44, Mark Hills wrote:
> >> Could libpq be reasonably modified to allow this?
>
> > I believe it's doable in theory, no-one has just gotten around to it.
> > Patches are welcome.
>
> Can't you do that today w
On Mon, Oct 31, 2011 at 12:09 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 31.10.2011 17:44, Mark Hills wrote:
>>> Could libpq be reasonably modified to allow this?
>
>> I believe it's doable in theory, no-one has just gotten around to it.
>> Patches are welcome.
>
> Can't you do that t
On 31.10.2011 19:09, Tom Lane wrote:
Heikki Linnakangas writes:
On 31.10.2011 17:44, Mark Hills wrote:
Could libpq be reasonably modified to allow this?
I believe it's doable in theory, no-one has just gotten around to it.
Patches are welcome.
Can't you do that today with a multi-command
Heikki Linnakangas writes:
> On 31.10.2011 17:44, Mark Hills wrote:
>> Could libpq be reasonably modified to allow this?
> I believe it's doable in theory, no-one has just gotten around to it.
> Patches are welcome.
Can't you do that today with a multi-command string submitted to
PQsendQuery, f
I have nothing of substance to add, but
On Mon, Oct 31, 2011 at 17:44, Mark Hills wrote:
> Instead, it would be preferable to send multiple requests (down the TCP
> socket), and then receive multiple responses (in order).
HTTP calls this "pipelining". I think it's helpful to adopt this term
sinc
On 31.10.2011 17:44, Mark Hills wrote:
We have a user interface which fetches and displays many small pieces of
distinct information from a PostgreSQL database.
* fetches are simple lookups across a diverse set of tables,
in response to events on another data source
* uses PQsendQuery() on a
We have a user interface which fetches and displays many small pieces of
distinct information from a PostgreSQL database.
* fetches are simple lookups across a diverse set of tables,
in response to events on another data source
* uses PQsendQuery() on a non-blocking socket
But data fetches vi
14 matches
Mail list logo