Re: tuplestore API problem

Hitoshi Harada <umi.tanuki@gmail.com> writes:
> 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.

I think that the problem I found a couple days ago
http://archives.postgresql.org/pgsql-hackers/2009-03/msg01247.php
probably blows a hole in all these schemes.  After-the-fact
materialization of a TupleTableSlot won't protect any pass-by-reference
Datums that have already been fetched from that slot.  Perhaps we
could invent a coding rule that would prevent the situation, but
I think it would be awfully easy to mess up in any case where you
actually had a need to keep track of more than one current tuple.

I now think that the CVS-HEAD arrangement is about as good as we
should expect to get for 8.4.  The experiments I've been doing
suggest that the "extra" tuple copying isn't a major bottleneck
anyway...
        regards, tom lane