Thread: Is pgAdmin the only front-end to PostgreSQL debugger ? And is "a working pl/pgsql debugger" something core should care to maintain ?

Hallo PostgreSQL Hackers,


We recently discovered an error where pgAdmin fails when stepping into
nested function calls (
https://github.com/pgadmin-org/pgadmin4/issues/8443 ).

So while waiting for this to be fixed I would want to know if there
are other debugger front-ends that could be used to do basic debugging
of pl/pgsql code ?

And would these need a separate debugging extension, or is "debugging"
meant to be a generic PostgreSQL server feature that has a
well-defined API ?

I know there used to be another debugger as part of OmniDB which had
its own server-side extension as well, but wanted to know what is the
general thinking on this.

Is debugging pl/pgsq a generic feature of PostgreSQL core considering
that pl/pgsql itself kind of is ?

Should there be something similar for debugging plain SQL and possibly
other PL languages?

Should there perhaps be debugging support in psql ?

------
Hannu



Hi

čt 13. 2. 2025 v 18:00 odesílatel Hannu Krosing <hannuk@google.com> napsal:
Hallo PostgreSQL Hackers,


We recently discovered an error where pgAdmin fails when stepping into
nested function calls (
https://github.com/pgadmin-org/pgadmin4/issues/8443 ).

So while waiting for this to be fixed I would want to know if there
are other debugger front-ends that could be used to do basic debugging
of pl/pgsql code ?

If I remember, there was a independent application that was a plpgsql debugger, but it was in time before pgadmin 4

Maybe dbeaver uses it too. I think some commercial gui has support for debugging plpgsql, but I am not sure that it is.
 

And would these need a separate debugging extension, or is "debugging"
meant to be a generic PostgreSQL server feature that has a
well-defined API ?

Unfortunately  buildin API has not external interface. So everytime you need an extension that use internal plpgsql debug API or allow a access to some plpgsql data like stack or variables.

These extensions can be different, - plpgsql_check uses these API, plprofiler or pldebugger

If I remember well, the development of pldebugger or plprofiler was a fully independent project on Postgres core, and there was not any attempt to merge it upstream.

The internal buildin part is really minimalistic - just few hooks


I know there used to be another debugger as part of OmniDB which had
its own server-side extension as well, but wanted to know what is the
general thinking on this.

Is debugging pl/pgsq a generic feature of PostgreSQL core considering
that pl/pgsql itself kind of is ?

debugging plpgsql is independent of the PostgreSQL core.


Should there be something similar for debugging plain SQL and possibly
other PL languages?

I can imagine this - there can be some common API supported by language handlers.
 

Should there perhaps be debugging support in psql ?

psql does not support asynchronous API, so the implementation in psql really should not be simple. Moreover, I doubt that users want to use a debugger with a GUI similar to gdb. And it isn't possible to design a better UI directly in psql. I can imagine supporting some external debuggers executed inside / or outside the same terminal that communicates with psql by some bidirect pipe (psql will be used like a proxy).  Then can be designed some application similar to Borland debugger. This can be a very nice feature with probably not too much code, but handling bidirect pipes isn't trivial. Tuning reading from pipe for pspg for some less usual patterns was not nice work (and there the communication is significantly more simple than for debugger).

Regards

Pavel

------
Hannu


On Thu, Feb 13, 2025 at 8:10 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> Hi
>
> čt 13. 2. 2025 v 18:00 odesílatel Hannu Krosing <hannuk@google.com> napsal:
>>
>> Hallo PostgreSQL Hackers,
>>
>>
>> We recently discovered an error where pgAdmin fails when stepping into
>> nested function calls (
>> https://github.com/pgadmin-org/pgadmin4/issues/8443 ).
>>
>> So while waiting for this to be fixed I would want to know if there
>> are other debugger front-ends that could be used to do basic debugging
>> of pl/pgsql code ?
>
>
> If I remember, there was a independent application that was a plpgsql debugger, but it was in time before pgadmin 4
>
...
>> Should there perhaps be debugging support in psql ?
>
> psql does not support asynchronous API, so the implementation in psql really should not be simple. Moreover,
> I doubt that users want to use a debugger with a GUI similar to gdb.

It would be good to have some simple fallback in case the shiny GUI
things don't work.

For example python has its pdb module and node.js has a "debugging
mode" where you can set breakpoints and single-step through your code.

> And it isn't possible to design a better UI directly in psql. I can imagine supporting some external debuggers
executedinside / or outside the same terminal that communicates with psql by some bidirect pipe (psql will be used like
aproxy).  Then can be designed some application similar to Borland debugger. This can be a very nice feature with
probablynot too much code, but handling bidirect pipes isn't trivial. Tuning reading from pipe for pspg for some less
usualpatterns was not nice work (and there the communication is significantly more simple than for debugger). 

So a possibly better way could be adding pl/pgsql debugging support to
something widely used like VSCode ?

--
Hannu



Hi

pá 14. 2. 2025 v 0:37 odesílatel Hannu Krosing <hannuk@google.com> napsal:
On Thu, Feb 13, 2025 at 8:10 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> Hi
>
> čt 13. 2. 2025 v 18:00 odesílatel Hannu Krosing <hannuk@google.com> napsal:
>>
>> Hallo PostgreSQL Hackers,
>>
>>
>> We recently discovered an error where pgAdmin fails when stepping into
>> nested function calls (
>> https://github.com/pgadmin-org/pgadmin4/issues/8443 ).
>>
>> So while waiting for this to be fixed I would want to know if there
>> are other debugger front-ends that could be used to do basic debugging
>> of pl/pgsql code ?
>
>
> If I remember, there was a independent application that was a plpgsql debugger, but it was in time before pgadmin 4
>
...
>> Should there perhaps be debugging support in psql ?
>
> psql does not support asynchronous API, so the implementation in psql really should not be simple. Moreover,
> I doubt that users want to use a debugger with a GUI similar to gdb.

It would be good to have some simple fallback in case the shiny GUI
things don't work.

For example python has its pdb module and node.js has a "debugging
mode" where you can set breakpoints and single-step through your code.

Minimally in psql, you cannot do anything until the query is ended.  PLdebugger allows debugging from a separate session, and implements its own network protocol. This can be a possible security issue. When PLdebugger is not installed, then there is not a security risk.

So the support in psql is not a small change. plpgsql_check supports tracing, plpgsql byself supports RAISE NOTICE. I think it is enough for these old school developers.
Can be nice to do something better, but there are no customers. Probably, there can be nicer features for psql - like supports some richer scripting, maybe lua or similar language, custom commands, custom reports, etc.

It would be nice to debug the plpgsql function inside a gdb like C function, but probably it is not possible.



> And it isn't possible to design a better UI directly in psql. I can imagine supporting some external debuggers executed inside / or outside the same terminal that communicates with psql by some bidirect pipe (psql will be used like a proxy).  Then can be designed some application similar to Borland debugger. This can be a very nice feature with probably not too much code, but handling bidirect pipes isn't trivial. Tuning reading from pipe for pspg for some less usual patterns was not nice work (and there the communication is significantly more simple than for debugger).

So a possibly better way could be adding pl/pgsql debugging support to
something widely used like VSCode ?


I don't have enough knowledge in this area, but I think there can be support for gdb or maybe other common projects, and then debugging can be possible from vi, emacs for dinosaurs like me, or from eclipse, dbeaver, vscode for people.

Regards

Pavel
 

--
Hannu