Re: [PATCHES] libpq type system 0.9a

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/

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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