Re: [GENERAL] stored procedure revisited - Mailing list pgsql-general

OK.  Stored procedures are one of the most powerful tools available in
database design and implementation.  U guys/gals forget that placing
business rules in stored procedures allows for flexibility and modular
reusability of code as well as speeds up such commonly used queries.
Although I have never had the need to use stored procedures (never had a
project that used PostgreSQL that was large enuff), PostgreSQL allows u to
create SQL functions...which I believe meet the criteria u need for stored
procedures?

I could be wrong, but I dont know of any database that allows you to run an
SQL stmt without having the engine process the entire query in the
background.  Even those that return limited sets must execute a sort on the
entire dataset before a subset can be returned...

Stored Procedures have always been the strong point of Oracle :)

----- Original Message -----
From: Yin-So Chen <ychen1@uswest.net>
To: <pgsql-general@postgreSQL.org>
Sent: Tuesday, October 12, 1999 6:41 PM
Subject: Re: [GENERAL] stored procedure revisited


> amy cheng wrote:
> >
> > >I am not even
> > >sure if functions achieve what SP is supposed to achieve - saving the
> > >server time from reparsing the queries; I have a feeling that
>functions
> > >are also just place-holders at this point.
> >
> > anybody can comment? pg's dbd does not have "prepare", so, seems
> > that you are right! However, who cares that kind of performance?
> >
>
> Well, I can't speak for others, but I know I care, and it seems that you
> don't care :)  But you probably care, too.  Wouldn't you want to have
> the ability to convince your boss that PG not only is free, but it also
> matches the capability and kicks the day light out of [substitute your
> most-hated commercial RDBMS here]? :)
>
> Seriously though, SP is a good thing to have.  It increases the
> performance of the server, and it also increases your personal
> productivity as well (no-longer thinking about work-arounds).  Wouldn't
> you want DBD's prepare statement work as advertised?  Ususally,
> performance/abstraction are inversely proportional, e.g., C runs faster
> than Perl but it's also harder to learn and use.  However, here's a case
> that performance/abstraction are directly porportional - not only does
> SP increases the performance, it also folds the procedural layer into
> the database.  Seems like a win-win situation.
>
> I have a feeling that SP has been such a _dead_issue_ for so long that
> no one seems to think about it (when people do it seems to be just about
> work-arounds).  But as PG's development moves on, this is a good piece
> of technology to include, just like MVCC.  It's not due to chances that
> commercial RDBMS have it (even Access has it, after a fashion).  If you
> feel the same way (SP makes the program & life better), please raise
> your voice so the developers can hear it (I certainly hope to make this
> into their agenda).  If you don't feel the same way, please raise your
> voice too.  Maybe I will be convinced that it wasn't such a good idea
> after all :)
>
> Regards,
>
> yin-so chen
>
> ************
>
>