From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Hallgren <thomas(at)tada(dot)se> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> |
Subject: | Re: Proposal for debugging of server-side stored procedures |
Date: | 2006-05-29 18:29:06 |
Message-ID: | 15787.1148927346@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Hallgren <thomas(at)tada(dot)se> writes:
> I think this is a bad idea. PL/Java will use either shared memory or a
> socket to attach and as you already mentioned, when using C, a gdb
> will attach directly using the pid. I wouldn't be too surprised if
> Perl, Python, and PHP all have a similar solution and thus have no
> benefit from additions to the FE/BE protocol. IMO, debugging should be
> language specific and take place in a separate channel. There's no
> gain whatsoever mixing it with the FE/BE protocol.
It may well be that for plperl and friends we can kick the problem off
to language-specific debuggers --- indeed, one of the first things we
need to do is look at those to see what we can avoid reinventing.
But what of plpgsql?
Also, any solution of this type probably requires that the person doing
debugging have database superuser access (in fact, be logged directly
into the server machine as the postgres user). It'd be nice to have an
approach that could be used by non-superusers to debug their trusted-PL
functions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2006-05-29 19:07:26 | Re: Proposal for debugging of server-side stored procedures |
Previous Message | Magnus Hagander | 2006-05-29 18:26:00 | Re: anoncvs still slow |