Re: [HACKERS] SQL procedures
От | Pavel Stehule |
---|---|
Тема | Re: [HACKERS] SQL procedures |
Дата | |
Msg-id | CAFj8pRDv5gxMDy-CikqY68haaNXJ6paNucz-3uzgMCATYirWMw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] SQL procedures (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2017-11-14 17:14 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
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.
regards, tom lane
В списке pgsql-hackers по дате отправления: