Re: tuplestore API problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tuplestore API problem
Date
Msg-id 9457.1238167146@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:
> 2009/3/27 Hitoshi Harada <umi.tanuki@gmail.com>:
>> 2009/3/27 Tom Lane <tgl@sss.pgh.pa.us>:
>>> A brute-force solution is to change tuplestore_gettupleslot() so that it
>>> always copies the tuple, but this would be wasted cycles for most uses
>>> of tuplestores. �I'm thinking of changing tuplestore_gettupleslot's API
>>> to add a bool parameter specifying whether the caller wants to force
>>> a copy.

> Here's the patch. Hope there are no more on the same reason. It seems
> that we'd need to implement something like garbage collector in
> tuplestore, marking and tracing each row references, if the complete
> solution is required.

I don't like this; I'm planning to go with the aforementioned API
change instead.  The way you have it guarantees an extra copy cycle
even when tuplestore is already making a copy internally; and it doesn't
help if we find similar problems elsewhere.  (While I'm making the
API change I'll take a close look at each call site to see if it has
any similar risk.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: psql: Make tab completion work for ANALYZE VERBOSE ...
Next
From: Tom Lane
Date:
Subject: Re: 8.4 open items list