On 2020-01-03 18:00:01 -0500, Tom Lane wrote:
> 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.)
+1 to all of this.
