From: | Jarosław Nozderko <jaroslaw(dot)nozderko(at)polkomtel(dot)com(dot)pl> |
---|---|
To: | "Joe Conway" <mail(at)joeconway(dot)com> |
Cc: | "Pgsql-General (E-mail)" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Stored procedures returning rowsets |
Date: | 2002-08-12 08:55:55 |
Message-ID: | 250B3114DA16D511B82C00E0094005F809AEA7D5@MSGWAW11 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Joe and Neil,
> I see Neil answered your question, but I'll add to it a bit.
> If you're
> looking for something like the way Sybase stored procedures work (I
> haven't used Sybase but I presume it is similar to MS SQL
> Server), you
I've heard that MS SQL Server was modeled after Sybase, but I'm
not sure if this is true.
> won't see it in 7.3, at least. In other words, do you want to do:
>
> exec sp_my_proc_name
>
> and have it return un arbitrarily formed result set?
>
It would be nice.
> We have had some discussions regarding that, but decided in favor of
> table functions because they are much more useful in many
> ways. You can
> join them with other tables, and apply selection criteria to their
> output. And the anonymous composite type feature recently added will
> improve the flexibility of the table function approach greatly. Also
> there is a patch waiting to be accepted which will allow the
> creation of
> named composite types which are not tables or views.
>
> But, I do agree that sometimes the MSSQL/Sybase approach is
> very useful.
> Maybe for 7.4 if enough people can be convinced. There have
> been recent
> discussions regarding implementing "CREATE PROCEDURE" and "CALL
> my_procedure" which are steps in this direction.
>
> Joe
>
In my opinion, it's perfectly normal and very usful to retrieve
arbitrary data from database. Stored procedures are really helpful
here, for the following reasons:
- code is stored on the server side, compiled, optimized, etc.
It's much more efficient than planning and optimizing each incoming
query,
- query is a business logic - if it's located in each client,
it's harder to maintain the whole system,
- even the calls to procedures/functions are usually much shorter
than underlying queries - it may decrease network traffic.
Perhaps not all these factors are always important, but in big and
heavy loaded systems it's really unimaginable to send "raw" queries.
I work with billing system of the cell phone operator and that's
definitely a good example of such situation.
I think this is the major drawback (there are not many of them :))
of Postgres comparing to commercial databases. I know about
several cases where Postgres was considered to be used and was
rejected just for this reason.
Anyway, it's great product :)
Regards,
Jarek
Jaroslaw Nozderko
GSM +48 601131870 / Kapsch (22) 6075013
jaroslaw(dot)nozderko(at)polkomtel(dot)com(dot)pl
IT/CCBS/RS - Analyst Programmer
From | Date | Subject | |
---|---|---|---|
Next Message | Darko Prenosil | 2002-08-12 11:02:06 | Re: libpq |
Previous Message | frbn | 2002-08-12 08:45:05 | Re: libpq |