Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2020-Jan-03, Robert Haas wrote:
>> Then every time we add a function, or anything else, we can bikeshed
>> about whether it should go in pg_catalog or pg_extra!
> Yeah, I was just thinking about that :-) I was thinking that all
> standard-mandated functions, as well as system functions, should be in
> pg_catalog; and otherwise stuff should not get in the user's way.
I think that ship sailed a long time ago, frankly.
Why is it that this particular proposal is such a problem that we
need to redesign how we add features? There are currently 2977
rows in a default installation's pg_proc, with 2447 unique values
of proname. Certainly at least a couple of thousand of them are not
standard-mandated; despite which there are only 357 named 'pg_something'.
gcd and/or lcm are not going to move the needle noticeably.
I'd also submit that just pushing a bunch of built-in stuff into a
schema that's behind the users' schema instead of in front doesn't
mean that all is magically better. There are still going to be the
same issues that make CVE-2018-1058 such a problem, but now we get
to have them in both directions not just one:
* a system-supplied function in "pg_extra" could still capture a call
away from a user-supplied one in an earlier schema, if it is a better
match to the actual argument types;
* malicious users now have a much better chance to capture other
people's calls to "pg_extra" functions, since they can just drop an
exact match into public.
(BTW, I'm pretty sure we've had this conversation before. I
definitely recall a proposal to try to move functions not meant
for user consumption at all, such as index support functions,
into a whole other schema that wouldn't be in the path period.
It went nowhere, partly because those functions don't seem to
be big problems in practice.)
regards, tom lane
