From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 18:32:04 |
Message-ID: | 47FE5D24.9020706@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> 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
>
Yeah, "dup" wasn't the best name.
You need more arguments to makeresult though, since you reomved the
'source' result. You need binary, cmdStatus, noticeHooks and
client_encoding.
PQmakeResult(conn,
PQcmdStatus(res),
PQbinaryTuples(res),
?client_encoding?,
?noticeHooks?,
ntups, /* this interacts with setfieldvalue */
numAttributes,
attDescs);
For client_encoding and noticeHooks, the conn can be NULL. Previously,
we copied this info from the source result when conn was NULL.
> producing a zero-row PGRES_TUPLES_OK result that you can then
>load with data via PQresultSetFieldValue calls.
I like this idea but you removed the 'ntups' argument. There is no way
to adjust ntups after the makeresult call, its a private member and
setfieldvalue has no concept of incrementing ntups. Since you are not
appending a tuple like pqAddTuple, or inserting one, you can't increment
ntups in setfieldvalue.
But, you could have a function like PQresultAddEmptyTuple(res) which
would have to be called before you can set field values on a tup_num.
The empty tuple would grow tuples when needed and increment ntups. The
new tuple would be zerod (all NULL values).
....something like below
res = PQmakeResult(...);
for(ntups)
{
PQresultAddEmptyTuple(res); // or PQresultMakeEmptyTuple?
for(nfields)
PQresultSetFieldValue(res, tup_num, field_num, ....);
}
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-04-10 18:50:29 | Re: Indexam interface proposal |
Previous Message | Tom Lane | 2008-04-10 18:20:29 | Re: Index AM change proposals, redux |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-04-10 18:56:08 | Re: [HACKERS] Including Snapshot Info with Indexes |
Previous Message | Tom Lane | 2008-04-10 17:40:53 | Re: [PATCHES] libpq type system 0.9a |