| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Allow substitute allocators for PGresult. |
| Date: | 2011-11-12 01:34:40 |
| Message-ID: | 20111112013439.GO24234@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Heikki's idea is probably superior so far as PG backend usage is
> concerned in isolation, but I wonder if there are scenarios where a
> client application would like to be able to manage libpq's allocations.
The answer to that is certainly 'yes'. It was one of the first things
that I complained about when moving from Oracle to PG. With OCI, you
can bulk load results directly into application-allocated memory areas.
Haven't been following the dblink discussion, so not going to comment
about that piece.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeroen Vermeulen | 2011-11-12 04:21:10 | Re: foreign key locks, 2nd attempt |
| Previous Message | Thom Brown | 2011-11-12 00:08:35 | Re: VACUUM touching file but not updating relation |