On 2014-04-25 11:22:09 -0400, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
