From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] SQL procedures |
Date: | 2017-11-14 22:47:25 |
Message-ID: | 5b643520-59fd-b62a-102c-184e884149c9@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/14/17 11:14, Tom Lane wrote:
>> 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?
Yes, that is defined that way by the SQL standard.
The point about the overlap refers more to the internals. The entire
parsing, look-up, type-resolution, DDL handling, and other things are
the same.
So for both of these reasons I think it's appropriate to use the same
catalog.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-11-14 23:07:54 | Re: [HACKERS] Commits don't block for synchronous replication |
Previous Message | legrand legrand | 2017-11-14 22:40:56 | Re: Transaction control in procedures |