For obscure reasons, some buildfarm members are now generating
complaints about plpgsql_call_handler's "retval" variable possibly
being used uninitialized. It seems no less safe than it was before
that commit, but these complaints are (mostly?) new. I trust that
initializing the variable where it's declared will be enough to
shut that up.
I also notice that some compilers are warning about setjmp clobber
of the same variable, which is maybe a bit more defensible. Mark
it volatile to silence that.
Also, rearrange the logic to give procedure_resowner a single
point of initialization, in hopes of silencing some setjmp-clobber
warnings about that. (Marking it volatile would serve too, but
its sibling variables are depending on single assignment, so let's
stick with that method.)
Discussion: https://postgr.es/m/
[email protected]
bool nonatomic;
PLpgSQL_function *func;
PLpgSQL_execstate *save_cur_estate;
- ResourceOwner procedure_resowner = NULL;
- Datum retval;
+ ResourceOwner procedure_resowner;
+ volatile Datum retval = (Datum) 0;
int rc;
nonatomic = fcinfo->context &&
* Therefore, be very wary of adding any code between here and the PG_TRY
* block.
*/
- if (nonatomic && func->requires_procedure_resowner)
- procedure_resowner =
- ResourceOwnerCreate(NULL, "PL/pgSQL procedure resources");
+ procedure_resowner =
+ (nonatomic && func->requires_procedure_resowner) ?
+ ResourceOwnerCreate(NULL, "PL/pgSQL procedure resources") : NULL;
PG_TRY();
{
{
plpgsql_exec_event_trigger(func,
(EventTriggerData *) fcinfo->context);
- retval = (Datum) 0;
+ /* there's no return value in this case */
}
else
retval = plpgsql_exec_function(func, fcinfo,