On Mon, 2006-02-06 at 13:28 +0100, Csaba Nagy wrote:
> For me the usage pattern would be: log all params, bind time values, on
> the same log line as "log_min_duration" entries. That's what I need to
> know which are the non-performant queries, and it also helps on
> occasions to identify applicat
Simon,
For me the usage pattern would be: log all params, bind time values, on
the same log line as "log_min_duration" entries. That's what I need to
know which are the non-performant queries, and it also helps on
occasions to identify application problems.
In any case all your plans sound very
On Mon, 2006-01-30 at 17:19 -0500, Bruce Momjian wrote:
> Ted Powell wrote:
> > On Mon, Jan 30, 2006 at 04:31:29PM -0500, Bruce Momjian wrote:
> > >
> > > I assume it is this TODO:
> > >
> > > * Allow protocol-level BIND parameter values to be logged
> > >
> > >
> > >
On Mon, Jan 30, 2006 at 05:19:23PM -0500, Bruce Momjian wrote:
> [...]
> > > * Allow protocol-level BIND parameter values to be logged
> [...]
> > That's it! (I should have thought to look in the TODO.)
> >
> > Has any design work been done on this?
>
> No. I am with Simon Riggs today at my ho
Ted Powell wrote:
> On Mon, Jan 30, 2006 at 04:31:29PM -0500, Bruce Momjian wrote:
> >
> > I assume it is this TODO:
> >
> > * Allow protocol-level BIND parameter values to be logged
> >
> >
> > ---
> >
> > Ted Powell
On Mon, Jan 30, 2006 at 04:31:29PM -0500, Bruce Momjian wrote:
>
> I assume it is this TODO:
>
> * Allow protocol-level BIND parameter values to be logged
>
>
> ---
>
> Ted Powell wrote:
> > Our development group nee
I assume it is this TODO:
* Allow protocol-level BIND parameter values to be logged
---
Ted Powell wrote:
> Our development group needs to have the option of logging all SQL
> statements including substituted param
Ted Powell <[EMAIL PROTECTED]> writes:
> Has this not been done simply because nobody has gotten around to it, or
> are there pitfalls?
What are you going to do with binary parameter values? Calling the
type's output converter is possible but not very pleasant.
> Also, the Datum params[i].value,
Our development group needs to have the option of logging all SQL
statements including substituted parameter values. Getting output in the
form:
... WHERE contact.login_con = $1 AND company.login_co = $2
was no problem, but nothing that I tried turning on in the config file
yielded values for
