On Mon, Oct 13, 2008 at 3:56 PM, Vladimir Dzhuvinov <[EMAIL PROTECTED]> wrote: > 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?
Not too much, there hasn't been a huge emphasis on getting them because we already have functions which are extremely powerful. > 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. Using temp tables inside a function isn't hacky. It was just awkward in older versions of postgresql because of limitations of the postgresql engine. > 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 :) If you are the type of programmer that likes to use the database as an engine to make your application development easier, you will eventually regret your decision. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
