Re: PQgetssl() and alternative SSL implementations - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: PQgetssl() and alternative SSL implementations
Date
Msg-id 20140819184015.GJ16422@tamriel.snowman.net
Whole thread Raw
In response to Re: PQgetssl() and alternative SSL implementations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> >> Um, libpq has recently gained the ability to return result fragments,
> >> right?  Those didn't exist when libpq-ification of odbc was attempted,
> >> as I recall -- perhaps it's possible now.
>
> > I was trying to remember off-hand if we still had that or not..  I
> > thought there was discussion about removing it, actually, but perhaps
> > that was something else.
>
> Sure,
> http://www.postgresql.org/docs/devel/static/libpq-single-row-mode.html
> That's a done deal, it won't be going away.

Ugh.  Yes, there's single-row mode, but I had been thinking there was a
'batch' mode available ala what OCI8 had, where you'd allocate a chunk
of memory and then have it filled directly by the library as rows came
back in until it was full (there was a similar 'bulk send' operation, as
I recall).  Perhaps it was the 'pipelining' thread that I was thinking
about.  Not really relevant, in any case.

> Whether it would solve ODBC's problem I don't know (and I'm not
> volunteering to do the work ;-))

It could work..  though it's certainly been a while since I looked at
the ODBC internals.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: bad estimation together with large work_mem generates terrible slow hash joins
Next
From: Robert Haas
Date:
Subject: Re: PQgetssl() and alternative SSL implementations