On Wed, 2008-02-27 at 10:54 -0800, Neil Conway wrote:
> Barring any objections, I'll apply this to HEAD and back branches
> tonight or tomorrow.
Applied to HEAD, REL8_3_STABLE, and REL8_2_STABLE. (I can backpatch
further if anyone feels strongly about it.)
-Neil
---(end
Neil Conway <[EMAIL PROTECTED]> writes:
> On Wed, 2008-02-27 at 15:07 -0500, Tom Lane wrote:
>> Negative refcount does not prove that the SRF itself hasn't
>> still got a pointer to the tupdesc.
> That sounds quite bizarre. The SRF has already finished execution at
> this point, so keeping a point
On Wed, 2008-02-27 at 15:07 -0500, Tom Lane wrote:
> Negative refcount does not prove that the SRF itself hasn't
> still got a pointer to the tupdesc.
That sounds quite bizarre. The SRF has already finished execution at
this point, so keeping a pointer to the tupledesc around would only make
sense
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2008-02-26 at 00:17 -0800, Neil Conway wrote:
>> You didn't comment on my proposed solution (FreeTupleDesc() iff refcount
>> == -1).
I still find that entirely unsafe, particularly for something you
propose to back-patch into stable branches. Nega
On Tue, 2008-02-26 at 12:09 -0800, Neil Conway wrote:
> I'd like to apply this change to back branches reasonably soon, so if
> you have a better way to do the FreeTupleDesc() hack, let me know.
Barring any objections, I'll apply this to HEAD and back branches
tonight or tomorrow.
-Neil
--
On Tue, 2008-02-26 at 00:17 -0800, Neil Conway wrote:
> You didn't comment on my proposed solution (FreeTupleDesc() iff refcount
> == -1).
Attached is a revised version of this patch. It makes the
FreeTupleDesc() change described above, and fixes a bug: in
SRF_RETURN_DONE(), we need to be sure to
On Tue, 2008-02-26 at 03:13 -0500, Tom Lane wrote:
> "It's OK in the built-in SRFs" is disastrously different from "It's OK".
Right, I never said that, I was just commenting on your view that the
predominant use-case for SRFs is returning refcounted tupdescs.
You didn't comment on my proposed sol
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2008-02-25 at 21:00 -0500, Tom Lane wrote:
>> I find this part of the patch to be a seriously bad idea.
> AFAICS this is not true of any of the SRFs in the backend, which always
> return expendable tupdescs.
"It's OK in the built-in SRFs" is disas
On Mon, 2008-02-25 at 21:00 -0500, Tom Lane wrote:
> I find this part of the patch to be a seriously bad idea.
> nodeFunctionscan has no right to assume that the function has returned
> an expendable tupdesc; indeed, I would think that the other case is
> more nearly what's expected by the API for
Neil Conway <[EMAIL PROTECTED]> writes:
> if (funcTupdesc)
> + {
> tupledesc_match(node->tupdesc, funcTupdesc);
> + FreeTupleDesc(funcTupdesc);
> + }
> }
I find this part of the patch to be a seriously bad idea.
10 matches
Mail list logo
