Andrew Dunstan <and...@dunslane.net> writes:
> This doesn't look quite right. Shouldn't we unconditionally release the
> Tupledesc before the returns at lines 2118 and 2127, just as we do at
> the bottom of the function at line 2285?
I think Pavel's patch is probably OK as-is, because the tupdesc returned
by get_call_result_type isn't reference-counted; but I agree the code
would look cleaner your way. If the main exit isn't bothering to
distinguish this then the early exits should not either.
What I'm wondering about, though, is this bit at line 2125:
/* same logic as for json */
if (!have_record_arg && rec)
PG_RETURN_POINTER(rec);
If that's supposed to be the same logic as in the other path, then how
is it that !have_record_arg has anything to do with whether the JSON
object is empty? Either the code is broken, or the comment is.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
