Hello 2008/7/16 Milan Oparnica <[EMAIL PROTECTED]>: > Milan Oparnica wrote: >> >> It's simply to complicated to return recordsets through server-side stored >> procedures. They are obviously designed to do complex data manipulation, >> returning few output variables informing the caller about final results. >> Returning records through sets of user-defined-types is memory and >> performance waste (please see my previous post as reply to Steve for more >> details). Plus it's hard to maintain and make improvements to such a system. >> I hate to see 800 user types made for every query we made as stored >> procedure. > > Is this topic completely out of scope in Postgre ? > If I'm missing something too obvious or too important, please let me know > what. > > I run over and over through internet and Postgre documentation and still > found nothing. >
try to write prototype and show advantages. I am able to undestand advantages of persistent prep. stamenents, but I see some disadvatage too. Mainly you have to manage some shared memory space for stored plans. It's not easy task - MySQL develepoers can talk. Implemenation on postgresql is little bit dificult - lot of structures that lives in processed memory have to be moved to shared memory. This feature is nice, but question is - who do write it? Actually this problem is solved from outside - with pooling. Regards Pavel Stehule > Is there a better place to communicate with Postgre developers ? > > Sincerely, > > Milan Oparnica > > -- > Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-sql > -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql