Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)?
От | Vladimir Dzhuvinov |
---|---|
Тема | Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)? |
Дата | |
Msg-id | 48F3A802.9070001@valan.net обсуждение исходный текст |
Ответ на | Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)? ("Merlin Moncure" <mmoncure@gmail.com>) |
Ответы |
Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)?
Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)? |
Список | pgsql-general |
Hi Merlin, > Stored procedure support is a pretty complicated feature. They differ > with functions in two major areas: > > *) input/output syntax. this is what you are dealing with > *) manual transaction management. stored procedures should allow you > emit 'BEGIN/COMMIT' and do things like vacuum. > > IIRC, I don't think there was a consensus on the second point or if it > was ok to implement the syntax issues without worrying about > transactions. I understand the situation, that a range of facets such as syntax, SP i/o and the overall fit of SPs into the architecture of PG should be considered. What do the Postgres gurus say about stored procedures? My SQL experience is rather limited, but I've got the impression that every RDBMS has got its own philosophy about matters relational and I expect Posgresql to be no different. So probably an improvised hack wouldn't be of much use here and things should be thought over. Anyway, at this point I'm finished with my evaluation of Postgresql. The MySQL solution which I've got now works reasonably well. It's just that at this moment my investment into MySQL is still relatively small and I wanted to check my options before I dig myself too deeply into MySQL to make a potential sensible migration too expensive :) Maybe I'm going to revisit Postgresql again in 2009 or 2010 :) Vladimir -- Vladimir Dzhuvinov * www.valan.net * PGP key ID AC9A5C6C
Вложения
В списке pgsql-general по дате отправления: