Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > On 11/8/17 09:54, Tom Lane wrote: >> Do procedures of this ilk belong in pg_proc at all? It seems like a large >> fraction of the attributes tracked in pg_proc are senseless for this >> purpose. A new catalog might be a better approach.
> The common functionality between functions and procedures is like 98% > [citation needed], so they definitely belong there, even more so than > aggregates, for example.
No, I don't think so. The core reason why not is that in
SELECT foo(...) FROM ...
foo() might be either a plain function or an aggregate, so it's important that functions and aggregates share the same namespace. *That* is why they are in the same catalog. On the other hand, since the above syntax is not usable to call a SQL procedure, putting SQL procedures into pg_proc just creates namespacing conflicts. Do we really want the existence of a function foo(int) to mean that you can't create a SQL procedure named foo and taking one int argument?
It is good point.
I agree so catalogue should be separate. Because procedures should not be used in query, then lot of attributes has not sense there. Maybe in future, we would to implement new features for procedures and it can be a problem when we share catalogue with functions.
