Re: [PATCHES] libpq type system 0.9a

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: [PATCHES] libpq type system 0.9a
Дата
Msg-id
5204.1207849253@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:
> PGresult *PQresultDup(
>    PGconn *conn,
>    PGresult *res,
>    int ntups,
>    int numAttributes,
>    PGresAttDesc *attDescs);

I don't understand why this is a "dup" operation.  How can you "dup"
if you are specifying a new tuple descriptor?  I'd have expected
something like

PGresult *PQmakeResult(PGconn *conn, int numAttributes, PGresAttDesc *attDescs)

producing a zero-row PGRES_TUPLES_OK result that you can then load with
data via PQresultSetFieldValue calls.  (Even the conn argument is a bit
of a wart, but I think we probably need it so we can copy some of its
private fields.)

Copying an existing PGresult might have some use too, but surely that
can't change its tuple descriptor.
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Andrew Chernow
Дата:
От: Teodor Sigaev
Дата:
FAQ