At 01:33 11/09/2008, unordained wrote:

>2. Doesn't matter; triggers and stored procedures have the same byte limit on the amount of code you can stuff into them;

Not true. There is a 48KB limit on the total BLR size of each PSQL module (trigger or SP). Breaking large modules into smaller ones not only avoids this limit but makes maintaining PSQL suites cleaner, easier to test and less prone to undetected logic errors (just as with any programming system!)

>creating a separate SP just polutes the database namespace, which is already too easy to do;

Pollution is in the eye of the beholder, methinks. My modularised code is pollution to you. Your monolithic program is a horror to me and anyone else who has to maintain your code. As to namespaces, a functional object naming system should be an explicit objective of any database design. We all have the choice of clean or dirty in this respect! ;-)

There is a down-side to modularising PSQL, though, which will particularly bite a developer whose instincts are not attuned to modularity. If you change the inputs or outputs of a "downstream" module, you'll have to recompile the upstream modules, since they are wired to the old inputs. So it's not usually a good practice to extend the layers to great depths of dependency. Often it works best to have a "top-level" module whose job is to control the call stream and do the final actions. And ALWAYS to document!

>an extra procedure call seems unlikely to speed things up.

It won't. But it won't slow it down, either.

>It wouldn't change your concurrency situation at all.

This is true. This design needs a big re-think, as you correctly pointed out.

./heLen