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 (Andrew Chernow <ac@esilo.com>) |
Ответы |
Re: [PATCHES] libpq type system 0.9a
Re: [PATCHES] libpq type system 0.9a |
Список | pgsql-hackers |
Andrew Chernow <ac@esilo.com> 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 по дате отправления: