Guillaume Smet wrote:
> On 8/30/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > I thought about this, and because we are placing two pieces of
> > information on the same line, it seems "|" is the best choice.
>
> Good idea. It's far more readable with a pipe.
>
> > Oh. You want to pull the par
On 8/30/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
I thought about this, and because we are placing two pieces of
information on the same line, it seems "|" is the best choice.
Good idea. It's far more readable with a pipe.
Oh. You want to pull the parameters out of that. I am thinking yo
Guillaume Smet wrote:
> On 8/29/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Good point. I thought it was clear enough, but obviously not. I had a
> > similar case with bind, and used a comma to separate them:
> >
> > LOG: statement: prepare sel1, SELECT $1;
> > LOG: stateme
On 8/29/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Good point. I thought it was clear enough, but obviously not. I had a
similar case with bind, and used a comma to separate them:
LOG: statement: prepare sel1, SELECT $1;
LOG: statement: bind sel1, $1 = 'a''b'
For this one
Guillaume Smet wrote:
> On 8/29/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > DETAIL: prepare: SELECT $1; bind: $1 = 'a''b'
>
> I attached a trivial patch to add a dash between the prepare part and
> the bind part. People usually don't finish their queries with a semi
> colon so it's
On 8/29/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
DETAIL: prepare: SELECT $1; bind: $1 = 'a''b'
I attached a trivial patch to add a dash between the prepare part and
the bind part. People usually don't finish their queries with a semi
colon so it's more readable with a separator.
D
Bruce,
I made a few tests here and the backend terminates with a SIG11 when a
parameter has the NULL value (it was logged as "(null)" before). I
suspect the new code broke something (perhaps it's due to the
escaping).
--
Guillaume
---(end of broadcast)---
bruce wrote:
> BTom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Yes, I do. I have applied the attached patch to fix this issue and
> > > several others. The fix was to save the bind parameters in the portal,
> > > and display those in the executor output, if available.
> >
>
BTom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, I do. I have applied the attached patch to fix this issue and
> > several others. The fix was to save the bind parameters in the portal,
> > and display those in the executor output, if available.
>
> I have a feeling you just
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, I do. I have applied the attached patch to fix this issue and
> several others. The fix was to save the bind parameters in the portal,
> and display those in the executor output, if available.
I have a feeling you just blew away the 4% savings in
Guillaume Smet wrote:
> On 8/7/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Updated patch attached. It prints the text bind parameters on a single
> > detail line. I still have not seen portal names generated by libpq.
>
> I'm currently testing CVS tip to generate sample log files. I noticed
On 8/7/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Updated patch attached. It prints the text bind parameters on a single
detail line. I still have not seen portal names generated by libpq.
I'm currently testing CVS tip to generate sample log files. I noticed
that Bruce only patched log_stat
Applied. Changes are:
For protocol-level prepare/bind/execute:
o print user name for all
o print portal name if defined for all
o print query for all
o reduce log_statement header to single keyword
o print bind parameters as DETAIL if text mo
Sorry, forgot to show sample output:
LOG: prepare sel1: SELECT $1 + $2;
LOG: bind sel1: SELECT $1 + $2;
DETAIL: $1 = "8", $2 = "5"
LOG: execute sel1: SELECT $1 + $2;
LOG: prepare sel1: SELECT 3;
LOG: bind sel1: SELECT 3;
Bruce Momjian wrote:
> Tom Lane wrote:
> > Oliver Jowett <[EMAIL PROTECTED]> writes:
> > > A 50-parameter query could be .. interesting ..
> >
> > > I realize that you need this level of output to reflect what is
> > > happening at the protocol level, but seeing all the protocol detail is
> > >
Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
> > A 50-parameter query could be .. interesting ..
>
> > I realize that you need this level of output to reflect what is
> > happening at the protocol level, but seeing all the protocol detail is
> > not really what you expect when you
Oliver Jowett <[EMAIL PROTECTED]> writes:
> A 50-parameter query could be .. interesting ..
> I realize that you need this level of output to reflect what is
> happening at the protocol level, but seeing all the protocol detail is
> not really what you expect when you turn on basic statement log
On Sat, Aug 05, 2006 at 07:39:48PM +1200, Oliver Jowett wrote:
> Bruce Momjian wrote:
> >OK, updated patch, with output of text bind parameters. New output
> >is:
> >
> > LOG: prepare sel1: SELECT $1 + $2;
> > LOG: bind sel1: SELECT $1 + $2;
> > LOG: bind sel1: parameter 1:
Bruce Momjian wrote:
OK, updated patch, with output of text bind parameters. New output is:
LOG: prepare sel1: SELECT $1 + $2;
LOG: bind sel1: SELECT $1 + $2;
LOG: bind sel1: parameter 1: "8"
LOG: bind sel1: parameter 2: "5"
LOG: execut
OK, updated patch, with output of text bind parameters. New output is:
LOG: prepare sel1: SELECT $1 + $2;
LOG: bind sel1: SELECT $1 + $2;
LOG: bind sel1: parameter 1: "8"
LOG: bind sel1: parameter 2: "5"
LOG: execute sel1: SELECT $1 + $
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I modified the code to store the user statement name in the portal for
> > protocol execute, so I can print the user name at that time.
>
> Please forget that and print the portal name. I'm getting tired of
> repeating it, but: there
21 matches
Mail list logo
