Re: SQL:2011 Application Time Update & Delete

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SQL:2011 Application Time Update & Delete
Date: 2026-04-19 18:51:23
Message-ID: CA+renyVdyBcLzh2sFWUJ44A+N+7qL=f7rAyDOqFsTHTDb5q=SA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 19, 2026 at 11:10 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> > I have committed the patches 0001 through 0003.
>
> Coverity is complaining that rsi.isDone may be used uninitialized in
> ExecForPortionOfLeftovers. It's correct: that function is not obeying
> the function call protocol, and it's only accidental that it's not
> failing. In ValuePerCall mode the caller is supposed to initialize
> isDone (and isnull too) before each call. The canonical reference
> for this is execSRF.c, and it does that. So I think we need something
> like the attached.

Thanks for the patch! Your changes look good to me.

> I notice that execSRF.c also runs pgstat_init_function_usage and
> pgstat_end_function_usage around each call. That's not too important
> right now, but I wonder whether we should add it while we're looking
> at this. It would perhaps be important once we support user-defined
> withoutPortionProcs.

I agree we should do that. Here is a patch with that added to your changes.

I was curious why execSRF.c uses `rsinfo.isDone != ExprMultipleResult`
for the finalize parameter, because I don't think a SRF should ever
return ExprSingleResult, right? So I guess it is just to be cautious.
Makes sense. I followed that approach.

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com

Attachment Content-Type Size
v2-0001-Make-FOR-PORTION-OF-obey-SRF-protocol.patch text/x-patch 2.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message SATYANARAYANA NARLAPURAM 2026-04-19 18:58:46 Possible premature SNAPBUILD_CONSISTENT with DB-specific running_xacts
Previous Message Bruce Momjian 2026-04-19 18:36:57 Re: First draft of PG 19 release notes