Debugger
Stored routines are usually the hardest thing in a database to reason about: you can read the source, but you cannot see what it actually did. DBCode’s debugger runs a function or procedure on the server and pauses it wherever you set a breakpoint, so you can step through the logic line by line and inspect real values as they change.
It uses the native VS Code debug UI. Breakpoints go in the gutter of the routine’s source, and the Run and Debug view shows the call stack, variables, and watches exactly as it does for any other language.
Debugging requires a DBCode Pro subscription, and the database server needs to be set up for it. Each database documents its own requirements: see Supported Databases.
Starting a session
Section titled “Starting a session”Open the function or procedure from the database explorer, then start the debugger any of these ways:
- Click the Debug CodeLens above the routine definition
- Click the Debug icon in the editor title bar
- Right-click the routine in the database explorer and choose Debug
DBCode checks the server is ready, collects any arguments, and runs the routine. If the routine cannot be debugged (the wrong language, for example) it says so and names the reason rather than failing silently.
Debugging runs against the deployed source, which is the definition currently stored on the server. If the editor has unsaved changes, apply or revert them first so the lines you set breakpoints on match the lines the server executes.
Arguments
Section titled “Arguments”If the routine takes arguments, DBCode prompts for them in the results panel using the same parameter grid as query parameters, so the values are entered the same way you already enter them for a query.
- Type a value to pass it
- Leave a cell empty to use the routine’s own default, where it has one
- Enter
(null)to pass a SQLNULL - Enter
(empty)to pass an empty string, which an empty cell cannot express for an argument that has a default
Values are remembered per routine, so re-running a debug session keeps what you entered last time.
Stepping and inspecting
Section titled “Stepping and inspecting”Once paused you get the usual debug controls:
| Control | Behaviour |
|---|---|
| Continue | Run to the next breakpoint, or to the end |
| Step Over | Run the current line, then pause on the next one |
| Step Into | Step into a called routine that can also be debugged |
| Stop | End the session and cancel the running routine |
The Variables view lists the routine’s variables at the current line, and values update as you step. You can edit a variable’s value while paused to try a different path without changing the source.
The Watch view accepts variable names, so you can pin the few values you care about instead of scanning the whole list.
The Call Stack view shows the nesting when one routine calls another. Selecting a frame shows that frame’s variables.
Output and results
Section titled “Output and results”Everything the routine produces lands in the DBCode results panel:
- Messages the routine raises (such as
RAISE NOTICEin PL/pgSQL) stream into the panel as they happen, so you can watch progress while stepping - When the routine finishes, whatever it returns is shown as a normal result tab, the same as running it directly
Connections
Section titled “Connections”A debug session opens two dedicated connections of its own for as long as it runs: one that executes the routine and pauses inside it, and one that drives stepping and reads variables. They are separate from the pool your queries use, which is why a paused session shows up as extra backends on the server.
These connections are never released for inactivity, so you can sit on a breakpoint for as long as you need without the session dying underneath you. This is deliberate and applies regardless of any Editor Connection Idle Timeout you have configured: reconnecting would silently attach to a different backend, and the paused routine only exists on the original one. Both connections close as soon as the session ends.
Limits
Section titled “Limits”- Step Out is not available: step over, step into, and continue are supported
- Pause cannot interrupt a routine mid-run; use a breakpoint to stop where you need
- Watch expressions accept variable names only, not arbitrary expressions
- Breakpoints apply to the deployed source, so a routine that is redeployed while paused ends the session
Supported Databases
Section titled “Supported Databases”| Database | Requirements |
|---|---|
| PostgreSQL | The plugin_debugger plugin loaded, the pldbgapi extension installed, a superuser or routine-owner role, and a LANGUAGE plpgsql routine |