Re: [PATCHES] libpq type system 0.9a

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Chernow <ac(at)esilo(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] libpq type system 0.9a
Date: 2008-04-10 17:40:53
Message-ID: 5204.1207849253@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Andrew Chernow <ac(at)esilo(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2008-04-10 17:42:32 Re: Index AM change proposals, redux
Previous Message Andrew Chernow 2008-04-10 17:36:29 Re: [PATCHES] libpq type system 0.9a

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Chernow 2008-04-10 18:32:04 Re: [PATCHES] libpq type system 0.9a
Previous Message Andrew Chernow 2008-04-10 17:36:29 Re: [PATCHES] libpq type system 0.9a