Re: tuplestore API problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tuplestore API problem
Date
Msg-id 20236.1238263761@sss.pgh.pa.us
Whole thread Raw
In response to Re: tuplestore API problem  (Hitoshi Harada <umi.tanuki@gmail.com>)
Responses Re: tuplestore API problem  (Hitoshi Harada <umi.tanuki@gmail.com>)
List pgsql-hackers
Hitoshi Harada <umi.tanuki@gmail.com> writes:
> So I tried pass EState.es_tupleTables to tuplestore_begin_heap() to
> trace those TupleTableSlots. Note that if you pass NULL the behavior
> is as before so nothing's broken. Regression passes but I'm not quite
> sure EState.es_tupleTable is only place that holds TupleTableSlots
> passed to tuplestore...

I've got zero confidence in that, and it seems pretty horrid from a
system structural point of view even if it worked: neither tuplestore.c
nor its direct callers have any business knowing where all the slots
are.  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.

> I know you propose should_copy boolean parameter would be added to
> tuplestore_gettupleslot().

I already did it, and concluded that not only were all the
tuplestore_gettupleslot calls in nodeWindowAgg broken, but so was
nodeCtescan.  I'm open to reverting that patch if you have a better
solution though.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_migrator progress
Next
From: Dave Page
Date:
Subject: Re: 8.4 open items list