Re: [HACKERS] SQL procedures - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] SQL procedures
Date
Msg-id 5b643520-59fd-b62a-102c-184e884149c9@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] SQL procedures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] SQL procedures  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: legrand legrand
Date:
Subject: Re: Transaction control in procedures
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Commits don't block for synchronous replication