Re: Procedures versus the "fastpath" API

From: Noah Misch <noah(at)leadboat(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Procedures versus the "fastpath" API
Date: 2021-03-12 01:52:28
Message-ID: 20210312015228.GA3063597@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 10, 2021 at 10:03:24AM +0100, Laurenz Albe wrote:
> On Tue, 2021-03-09 at 14:15 -0500, Tom Lane wrote:
> > As for procedures, I'm of the opinion that we should just reject those
> > too, but some other security team members were not happy with that
> > idea. Conceivably we could attempt to make the case actually work,
> > but is it worth the trouble? Given the lack of field complaints
> > about the "invalid transaction termination" failure, it seems unlikely
> > that it's occurred to anyone to try to call procedures this way.
> > We'd need special infrastructure to test the case, too, since psql
> > offers no access to fastpath calls.
> >
> > A compromise suggestion was to prohibit calling procedures via
> > fastpath as of HEAD, but leave existing releases as they are,
> > in case anyone is using a case that happens to work.

(That was my suggestion.)

> The "invalid transaction termination" failure alone doesn't
> worry or surprise me - transaction handling in procedures only works
> under rather narrow conditions anyway (no SELECT on the call stack,
> no explicit transaction was started outside the procedure).
>
> If that is the only problem, I'd just document it. The hard work is
> of course that there is no other problem with calling procedures that
> way. If anybody wants to do that work, and transaction handling is
> the only thing that doesn't work with the fastpath API, we can call
> it supported and document the exception.

I'd be fine with that, too.

> In case of doubt, I would agree with you and forbid it in HEAD
> as a corner case with little real-world use.

The PQfn(some-procedure) feature has no known bugs and no known users, so I
think the decision carries little weight. Removing the feature would look
wise if we later discover some hard-to-fix bug therein. Removal also obeys
the typical pattern that a given parse context accepts either procedures or
functions, not both. Keeping the feature, at least in back branches, would
look wise if it avoids urgent s/PQfn/PQexecParams/ work for some user trying
to update to 13.3.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-03-12 01:59:48 Re: Hybrid Hash/Nested Loop joins and caching results from subplans
Previous Message David Rowley 2021-03-12 01:49:29 Re: Hybrid Hash/Nested Loop joins and caching results from subplans