Re: [HACKERS] SQL procedures

2017-11-14 17:14 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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.

> regards, tom lane
>
>