Dave Page wrote:
> Peter Eisentraut wrote:
> > Dave Page wrote:
> >> Because PostgreSQL allows return values and IN/OUT/INOUT parameters
> >> on the same routine, we use the first part of the definition only
> >> when making our distinction.
> >>
> >> Source: section 4.27, SQL-invoked Routines in
> >> SWD-02-Foundation-2003-09
> >
> > That same clause also contains various arguments against pgAdmin's
> > definition. For example, all procedures must be invoked using the CALL
> > statement, which PostgreSQL doesn't have. But that is not the point.
> > If you were writing sqlAdmin, then I'd say you are right. But in
> > PostgreSQL we have made conscious efforts to present all programming
> > interfaces under a uniform "function" label, so I think it does users a
> > disservice if the GUI handles it differently.
> >
> > For that matter, what is supposed to be the practical benefit of this
> > distinction?
>
> As I said, it's a historical design that came about when EDB first
> introduced stored procedures. pgAdmin maintained the distinction mainly
> because many users coming from other DBMSs seem to get confused by the
> whole functions/SPs thing.
>
> I believe our interpretation of the distinction is valid, but I'm
> neither for or against making that distinction as I can see both sides
> of the argument from the user perspective.
FWIW I've seen several reports of users confused because their functions
appeared under "stored procedures", and other users confused because
some of their stored procedures were being categorized as functions
while others as stored procedures.
It's good to know the reason for this.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.