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.
Regards, Dave
