Re: tuplestore API problem

Поиск
Список
Период
Сортировка
От Hitoshi Harada
Тема Re: tuplestore API problem
Дата
Msg-id e08cc0400903301827y5dbd5254k60e21a8a827c39c7@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tuplestore API problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: tuplestore API problem
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: can't load plpython
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PQinitSSL broken in some use casesf