On 2014-04-25 11:22:09 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-04-24 19:40:30 -0400, Tom Lane wrote:
> >> * Because HeapTupleGetDatum might allocate a new tuple, the wrong thing
> >> might happen if the caller changes CurrentMemoryContext between
> >> heap_form_tuple and HeapTupleGetDatum.
>
> > It's fscking ugly to allocate memory in a PG_RETURN_... But I don't
> > really have a better backward compatible idea :(
>
> It's hardly without precedent; see PG_RETURN_INT64 or PG_RETURN_FLOAT8 on
> a 32-bit machine, for starters. There's never been an assumption that
> these macros couldn't do that.
There's a fair bit of difference between allocating 8 bytes and
allocation of nearly unbounded size... But as I said, I don't really
have a better idea.
I agree that the risk from this patch seems more manageable than your
previous approach.
The case I am worried most about is queries like:
SELECT a, b FROM f WHERE f > ROW(38, 'whatever') ORDER BY f;
I've seen such generated by a some query generators for paging. But I
guess that's something we're going to have to accept.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services