Database Reference
In-Depth Information
Chapter 6. Debugging PL/pgSQL
This chapter is entirely optional. Since you have only produced the highest quality,
bug-free code using the best possible algorithms, this text is probably a waste of your
time. Of course your functions parse perfectly on the first try. Your views show exactly
what they should—according to the enviously complete business and technical doc-
umentation that you wrote last month. There is no need for version control on your
procedures, as there has only ever been a Version 1.
Since you are still reading this, I'm sure that you're a whole lot more like me. I spend
about 10 percent of my time writing new code, and about 90 percent of it editing the
mistakes and oversights that I (and others) made in the first 10 percent. In fact, it
could be argued that no new code is ever written at all. Actually, a more accurate de-
scription of the process is that a dumb assertion is made, and then edited until the
customer can no longer stand the
Quality Assurance
(
QA
) process. We then ship
the result in the hopes of being useful to the end user. Was that too much reality for
you? Sorry.
The objective of this chapter is to make you much faster at making mistakes. As a
by-product, you will also learn how to diagnose and fix them at an alarming rate of
speed. The net effect for which we are hoping is that your boss will assume you wrote
it correctly the first time. This is, of course, a lie, but a very useful one.
This concept is critical to agile software development. In that philosophy, it is called
"prototyping". The idea is to create a feature quickly and demonstrate it as a con-
versation point, rather than trying to produce an entire system (presumably perfectly)
from conceptual documentation. Other authors refer to it as "failing quickly". It is a re-
cognition that the first 3 or 4 development iterations will probably not be acceptable
to the customer, and shouldn't be advertised as final until some discussion has oc-
curred.
This process effectively requires the developer to "live" in the debugger. He continu-
ally changes the outputs and routines until the desired effect is achieved. PostgreSQL
has a wonderful set of debugging tools available to help you fix your mess. Let me
show you how they work.
