Hitoshi Harada <umi.tan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers