Re: Procedures versus the "fastpath" API

On 3/9/21 2:15 PM, Tom Lane wrote:
> So the question on the table is what to do about this.  As far as
> window functions go, it seems clear that fastpath.c should just reject
> any attempt to call a window function that way (or an aggregate for
> that matter; aggregates fail already, but with relatively obscure
> error messages).  Perhaps there's also an argument that window
> functions should have run-time tests, not just assertions, that
> they're called in a valid way.
> 
> 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.

+1

> 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.
> 
> Thoughts?

My vote would be reject using fastpath for procedures in all relevant branches.
If someday someone cares enough to make it work, it is a new feature for a new
major release.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development