From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | 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-09 19:33:47 |
Message-ID: | af40ef77-a187-646c-c6da-6ddf2448ebea@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2021-03-09 20:05:17 | Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs |
Previous Message | Joel Jacobson | 2021-03-09 19:30:21 | Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[] |