Re: tuplestore API problem - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: tuplestore API problem
Date
Msg-id e08cc0400903301827y5dbd5254k60e21a8a827c39c7@mail.gmail.com
Whole thread Raw
In response to Re: tuplestore API problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: tuplestore API problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2009/3/30 Tom Lane <tgl@sss.pgh.pa.us>:
> Hitoshi Harada <umi.tanuki@gmail.com> writes:
>> 2009/3/29 Tom Lane <tgl@sss.pgh.pa.us>:
>>> ... What might be a bit saner is to remember the slot last passed to
>>> tuplestore_gettupleslot for each read pointer.  The implication would be
>>> that we'd be assuming only one slot is used to fetch from any one read
>>> pointer, but that is probably a reasonable restriction.
>
>> Hm, this choice is better than mine. But if we take this, I suppose we
>> need to consider the way to break the restriction, for the case we
>> will be forced to use many TupleTableSlots on one read pointer.
>
> I don't think we'd ever be "forced" to do that; and it would be easy to
> add an Assert to tuplestore_gettupleslot to check that it gets the same
> slot on each call.  Someone who needed to save previous tuples would be
> advised to copy older tuples to some other slot after fetching them.

I don't think advising or documenting such restriction to the future
programmer is a good idea from the point of encapsulation. I've come
up with an idea, that the read pointers remember their last slot as
you suggest and materialize it when another slot comes in
tuplestore_gettupleslot() and forget the former one. By this, you
don't need the restriction above, adding minimum penalty that is paid
if and only if you pass more than one tupleslot to tuplestore, which
doesn't seem to be occurred currently.

Regards,



--
Hitoshi Harada


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: can't load plpython
Next
From: Tom Lane
Date:
Subject: Re: PQinitSSL broken in some use casesf