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

From Tom Lane
Subject Re: [HACKERS] SQL procedures
Date
Msg-id 19884.1510676091@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] SQL procedures  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] SQL procedures  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] SQL procedures  ("Daniel Verite" <daniel@manitou-mail.org>)
Re: [HACKERS] SQL procedures  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] parallelize queries containing initplans
Next
From: Peter Eisentraut
Date:
Subject: plpgsql test layout