I wrote:
> It does seem a bit annoying that something in plpgsql is apparently
> doing a fresh catalog lookup to find information that likely was
> already cached at the start of function execution. But I think that's
> a performance deficiency, not a bug per se.
I reproduced this issue locally (to avoid race conditions, I just had the
function drop itself ;-)) and traced the site of the failure to this
bit in plpgsql function exit:
/*
* Need to look up the expected result type. XXX would be
* better to cache the tupdesc instead of repeating
* get_call_result_type(), but the only easy place to save it
* is in the PLpgSQL_function struct, and that's too
* long-lived: composite types could change during the
* existence of a PLpgSQL_function.
*/
switch (get_call_result_type(fcinfo, &resultTypeId, &tupdesc))
The catalog access inside get_call_result_type is fairly essential,
because this function has OUT parameters, so its pg_proc row is the
ultimate source of truth about what it returns. We could imagine
caching the info earlier during function execution, but as the comment
says, that has its own failure modes ... and they're more important
ones in practice. So I'm afraid there's not much to be done to
improve this.
regards, tom lane
