"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Another possibility would be allowing users to specify certain GUC
> settings for backends that match certain criteria when they're spawned,
> such as what IP the client is connecting from, or what user it's
> authenticating as.
ALTER USER SET ...
On Wed, Jul 19, 2006 at 01:35:16PM -0400, Tom Lane wrote:
> > 1) I think the most straightforward way to load an instrumentation
> > plugin is to define a new custom GUC variable (using the
> > custom_variable_classes mechanism).
>
> This seems a bit messy and special-purpose. I see no good rea
Hi korry-san.
From: "korry"
>
> > I'm unqualified to comment on the server side design, but I was
> > wondering if there was consensus on how the client interface to the
> > debugger would work. From previous threads I saw DBGP mentioned
> > (http://xdebug.org/docs-dbgp.php), but I don't re
When the plugin's shared library gets loaded, one way or the other,
it should construct the function-pointer struct and then pass it to a
function defined by plpgsql (this lets us hide/postpone the decision
about whether there can be more than one active plugin).
korry <[EMAIL PROTECTED]> writes:
>> I see no good reason to tie
>> it to plpgsql; we'll just need another one for every other language.
>>
> Hmmm... but the plugins themselves would be language-specific.
You miss my point. The plugins will be language-specific but the
mechanism for selecting/lo
I'm unqualified to comment on the server side design, but I was
wondering if there was consensus on how the client interface to the
debugger would work. From previous threads I saw DBGP mentioned
(http://xdebug.org/docs-dbgp.php), but I don't recall seeing any final
commitment to it.
The patc
Hi Korry,
On Jul 21, 2006, at 12:51 PM, korry wrote:
Sorry to poke - but I'd like to get a patch submitted next week.
Any more comments? Thanks.
I'm unqualified to comment on the server side design, but I was
wondering if there was consensus on how the client interface to the
debugger
Sorry to poke - but I'd like to get a patch submitted next week. Any
more comments? Thanks.
-- Korry
Thanks
for the quick feedback.
1) I think the most straightforward way to load an instrumentation
plugin is to define a new custom GUC variable (using the
custom_v
Thanks for the quick feedback.
1) I think the most straightforward way to load an instrumentation
plugin is to define a new custom GUC variable (using the
custom_variable_classes mechanism).
This seems a bit messy and special-purpose.
Agreed, I'm not crazy about using a
korry <[EMAIL PROTECTED]> writes:
> I'm working on a patch that implements the PL/pgSQL instrumentation
> stuff (i.e. the PL/pgSQL debugger) that I discussed at the Anniversary
> Summit and I need some opinions (this seems like a good place to look
> for opinions :-)
Opinions R US ;-)
> 1) I
I'm working on a patch that implements the PL/pgSQL instrumentation
stuff (i.e. the PL/pgSQL debugger) that I discussed at the Anniversary
Summit and I need some opinions (this seems like a good place to look
for opinions :-)
A quick review: the PL/pgSQL debugger is designed as an optional
11 matches
Mail list logo
