From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] SQL procedures |
Date: | 2017-11-14 16:14:51 |
Message-ID: | 19884.1510676091@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-11-14 16:18:02 | plpgsql test layout |
Previous Message | Tom Lane | 2017-11-14 16:00:14 | Re: [HACKERS] parallelize queries containing initplans |