Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The other, probably more controversial bit of functionality is that there
>> needs to be a way to cause a backend to load a PL plugin shared library
>> without any cooperation from the connected client application.
> A similar issue applies to plain SQL that's not touching any PL: In the
> past, I encountered numerous situations where I'd have liked to take a
> peek at the current application's queries (on MSSQL, this can be done
> with SQL Profiler), but not have constant statement logging. IMHO it
> would be a good idea if
> - debugging could be turned on and off on-the-fly, e.g. to skip the app
> startup phase. Thus I question the statement "GUC variable is sufficient"
> - the mechnism would cover plain SQL too.
I'd turn that around: I think you are arguing for a way to change GUC
settings on-the-fly for a single existing session, without cooperation
from the client. You can do that now if you're desperate enough (change
postgresql.conf, SIGHUP just that backend, revert postgresql.conf
change) but I agree something easier would be nice. In any case the
problem needs a generic solution not something that only works for PL
plugin loading, so solving it within GUC seems right to me.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
