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
