Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] [PATCHES] log_statement output for protocol

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Oliver Jowett <oliver(at)opencloud(dot)com>, Dave Cramer <pg(at)fastcrypt(dot)com>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Postgres JDBC <pgsql-jdbc(at)postgresql(dot)org>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCHES] log_statement output for protocol
Date: 2006-08-30 18:21:18
Message-ID: 200608301821.k7UILIT21208@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbcpgsql-patches
Guillaume Smet wrote:
> On 8/29/06, Bruce Momjian <bruce(at)momjian(dot)us> 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, I must admit I prefer the colon we used before.
> Something like:
> LOG:  statement: prepare sel1: SELECT $1;
> LOG:  statement: bind sel1: $1 = 'a''b'
> seems better to me as after the colon, we have the details of the
> command which is the common sense of a colon.

OK, done.

> > I am concerned a dash isn't clear enough, and a semicolon is confusing.
> > Using a comma the new output is:
> >
> >         LOG:  duration: 0.023 ms  execute sel1
> >         DETAIL:  prepare: SELECT $1;,  bind: $1 = 'a''b'
> 
> A dash is clearer in this case IMHO. ;, is not very readable. But I
> can parse easily both forms so it's not a problem for me if you prefer
> a comma.

I thought about this, and because we are placing two pieces of
information on the same line, it seems "|" is the best choice.

> > Is that OK?  Patch attached and committed.  I also fixed the null bind
> > parameter bug.  It now displays $1 = NULL (no quotes used).
> 
> Cool. I'll test that.
> 
> > Other suggestions?
> 
> I'll compile this new version and make tests in the next few days to
> check everything is consistent and let you know.
> 
> I'm still struggling to find a regexp good enough to parse "statement:
> execute y ('a', 4, 'text, with a comma'::text);" :).

Oh.  You want to pull the parameters out of that.  I am thinking you
need something that will go over the line character by character with
some type of state machine, rather than just regex.

> Thanks a lot for your work on this subject. It will help us a lot when
> we use the JDBC driver.

Patch attached and applied.  New output:
	
	LOG:  statement: begin;
	LOG:  statement: prepare x as select $1::text;
	LOG:  statement: execute x ('a');
	DETAIL:  prepare: prepare x as select $1::text;
	LOG:  statement: commit;
	LOG:  statement: set log_statement = 'none';
	LOG:  duration: 0.222 ms  statement: set log_min_duration_statement = 0;
	LOG:  duration: 0.061 ms  statement: begin;
	LOG:  duration: 0.113 ms  statement: prepare y as select $1::text;
	LOG:  duration: 0.213 ms  statement: execute y ('a');
	DETAIL:  prepare: prepare y as select $1::text;
	LOG:  duration: 0.081 ms  statement: commit;
	LOG:  statement: prepare sel1: SELECT $1;
	LOG:  statement: bind sel1: $1 = 'a''b'
	DETAIL:  prepare: SELECT $1;
	LOG:  statement: execute sel1
	DETAIL:  prepare: SELECT $1;  |  bind: $1 = 'a''b'
	LOG:  duration: 0.445 ms  statement: SET log_min_duration_statement = 0;
	LOG:  duration: 0.018 ms  execute sel1
	DETAIL:  prepare: SELECT $1;  |  bind: $1 = 'a''b'

Additional comments?

-- 
  Bruce Momjian   bruce(at)momjian(dot)us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Attachment: /bjm/diff
Description: text/x-diff (2.4 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-08-30 19:35:44
Subject: Re: pgcrypto deprecated functions?
Previous:From: Tom LaneDate: 2006-08-30 18:07:26
Subject: Re: stats test on Windows is now failing repeatably?

pgsql-patches by date

Next:From: Joe ConwayDate: 2006-08-30 19:50:27
Subject: Re: BUG #2600: dblink compile with SSL missing libraries
Previous:From: Christopher BrowneDate: 2006-08-30 17:50:44
Subject: BUG #2600: dblink compile with SSL missing libraries

pgsql-jdbc by date

Next:From: Matt ChambersDate: 2006-08-30 23:11:23
Subject: jdbc3, pg 8.1.4 , and stored procedures
Previous:From: Marc HerbertDate: 2006-08-30 16:27:40
Subject: Re: Catching postgres exceptions - functions returning error values?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group