Re: Stored Procedure examples

From: Dave Page <dpage(at)postgresql(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-general(at)postgresql(dot)org, Walter Vaughan <wvaughan(at)steelerubber(dot)com>
Subject: Re: Stored Procedure examples
Date: 2007-02-15 12:51:33
Message-ID: 45D45755.4030900@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Nico Grubert 2007-02-15 12:58:22 gmake Error "/libpython2.4.a: could not read symbols: Bad value" with ./configure --with-python
Previous Message tonylaq 2007-02-15 11:48:55 Re: User privilege information.