Alvaro Herrera <alvhe...@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