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