[Spacewalk-devel] Path to PostgreSQL Update

Geoff O'Callaghan geoffocallaghan at gmail.com
Wed Jun 25 07:00:49 EDT 2008

On Wednesday 25 June 2008 06:23:08 Devan Goodwin wrote:
> Just finished a first draft of proposals for the
> https://fedorahosted.org/spacewalk/wiki/PathToPostgreSql wiki page.
> Partha has also added a section on analysis of how many stored
> procedures we have and how large they are.


> My strictly personal opinion is that we reap benefits in terms of
> portability, language syntax, testability, and generally more flexible
> and maintainable code if we cease the use of stored procedures. I

I'm not sure I agree with that assessment.  You're basically translating a 
shared element into a separate representation for every language that 
utilizes it - potentially leading to a range of inconsistencies depending on 
the language you do the work from.


> However despite the fact that the majority may wish to avoid these
> stored procedures, concerns have been raised that porting to
> application code will take too long, and we should instead focus on
> porting directly to PostgreSQL to get up and running as quickly as
> possible. (leaving removal of stored procedures as a project for
> another day) I suspect this concern is valid and that straight forward
> PL/SQL -> PL/pgSQL will be faster than PL/SQL -> application code, but
> I am not sure. I am concerned however with the maintenance costs and
> whether or not the procedures would ever be later removed. (i.e.
> eternal maintenance of dual stored procedure versions)

No matter how you do it.  If you want to support multiple database engines you 
are going to have increased maintenance costs.  Using stored procedures 
potentially reduces that complexity if you have multiple languages involved.  
It's 6 or one and half a dozen of the other.  You will have maintenance effort 
no matter how you do it, but if the goal is to have multi-language support as 
well as multi-database support then having a shareable element in the 
database does help reduce the pain in that regard - with other drawbacks of 


More information about the Spacewalk-devel mailing list