Re: [PATCHES] libpq type system 0.9a

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: [PATCHES] libpq type system 0.9a
Дата
Msg-id
21866.1207760895@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Re: [PATCHES] libpq type system 0.9a Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] libpq type system 0.9a Jeff Davis <pgsql@j-davis.com>
Re: [PATCHES] libpq type system 0.9a Florian Pflug <fgp.phlo.org@gmail.com>
Re: [PATCHES] libpq type system 0.9a Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] libpq type system 0.9a "Merlin Moncure" <mmoncure@gmail.com>
Andrew Chernow  writes:
>>> What parts of PGconn/PGresult do you need to touch that aren't exposed
>>> already?

> Don't need direct access to PGconn at all.

Oh, good, that makes things much easier.

> Also, we basically need write access to every member inside a result 
> object ... since we create our own for arrays and composites by copying 
> the standard result members over.

Hmm.  I guess it wouldn't be completely out of the question to expose
the contents of PGresult as part of libpq's API.  We haven't changed it
often, and it's hard to imagine a change that wouldn't be associated
with a major-version change anyhow.  We could do some things to make it
a bit more bulletproof too, like change cmdStatus from fixed-size array
to pointer to allocated space so that CMDSTATUS_LEN doesn't become
part of the API.

Alternatively, we could keep it opaque and expose a bunch of manipulator
routines, but that might be a lot more cumbersome than it's worth.
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Jeff Davis
Дата:
От: Claudio Rossi
Дата:
Сообщение: Segfault using heap_form_tuple
FAQ