Database Reference
In-Depth Information
Advantages of the debugger
The PL/pgSQL Debugger does not require any resources on the server when not
actually in use. Because it is invoked manually from within
pgAdmin3
, it is not resid-
ent in memory until it is actually called upon. This architecture does not require any
background processes or additional daemons for the sake of debugging.
Also, the PL/pgSQL Debugger does not require any special "calling" function to be
written to invoke the debugging process. There are no errors to trap, and no tables of
error codes to interpret. Everything necessary to the debugging process is available
in a simple window.
If you connect to your database as a
superuser
, you also have the ability to set a
global break point. This break point can be set on any function or trigger and it will
stop the next time any code path calls the function. This is particularly useful if you
want to debug your functions or triggers in the context of your entire running applic-
ation.
The greatest advantage of PL/pgSQL Debugger is that it does not require any spe-
cial rigging in the functions that are being debugged. There is no code to insert or
remove, and good coding practices do not need to be modified with respect to de-
bugging. There is no possibility to "forget" the debugging code when moving to pro-
duction. All of your PL/pgSQL functions are now instantly ready to debug without any
special action.
Disadvantages of the debugger
As you have become painfully aware, the installation of the debugger leaves a lot to
be desired. This debugger has not become very popular in the PostgreSQL commu-
nity at large because of the rather large learning curve involved, and that's just to get
it installed.
This form of debugging is meant for personal productivity while actively developing
functions. It does not work well as an automation tool.
