kleptog@svana.org (Martijn van Oosterhout) writes:
> On Mon, Jul 25, 2005 at 11:35:14AM +1000, Ezequiel Tolnay wrote:
>> Functions are not the same as stored procedures, but since PG lacks
>> stored procedures, there is a necessity to use functions instead.
>
> Ok, maybe I'm missing something, but the only difference between a
> procedure and a function is that a function returns a value and a
> procedure doesn't. There's no difference in capabilities so I don't
> really understand the problem here.
I'm in the same boat here. I don't grasp what is the *vital*
difference that makes a stored function, which differs from a stored
procedure in that it returns a value, so greatly different.
>> Stored procedures (in the RDBMSs that support them) are normally
>> used to 1) run batch processes, and 2) separate the interface from
>> the database logic (by interface, I mean an interface with the
>> client app). Functions on the other side are very convenient as a
>> kind of parameterisable or extended view, and (if there are stored
>> procedures available) not really intended as an interface with the
>> front-end.
>
> But AFAICS this is a distinction made by people (like in Pascal) but is
> not a distinction at all. As far as the system is concerned they are
> identical. Everything you can do in one of those "procedures" you can
> do in PostgreSQL now, so what is the problem?
What may possibly be a difference that *would* be real is the ability
to manage transactions in a procedure.
That is, to periodically invoke "COMMIT"...
I would think that there was *some* value in having a language that
allowed invoking COMMIT as opposed to treating it as an ignorable
externality...
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/sap.html
Rules of the Evil Overlord #78. "I will not tell my Legions of Terror
"And he must be taken alive!" The command will be: ``And try to take
him alive if it is reasonably practical.''"
<http://www.eviloverlord.com/>