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

Re: TODO item: list prepared queries

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-patches(at)postgresql(dot)org
Subject: Re: TODO item: list prepared queries
Date: 2005-12-30 22:55:23
Message-ID: 200512302255.jBUMtNk04780@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > One minor irritation is that the query string of prepared statements
> > created via SQL has "PREPARE ... AS" prefixed to it, whereas statements
> > prepared via the FE-BE protocol do not. This should probably be fixed,
> 
> That's debatable.  Earlier today, I was busy being annoyed all over
> again with the way that Bruce set up Parse/Bind/Execute logging to
> deliberately obscure the difference between a SQL PREPARE command and a
> protocol-level Parse operation.  I think it's a good thing to be able to
> tell which level a prepared statement came from.  Yeah, much of the time
> you may not care, but when you do care it's important.

I have applied the following patch to CVS HEAD to mark client-side
prepare/bind/execute statements with "[client]" so they can be easily
distinguished from SQL commands.  I hesitate to apply this logging
change to 8.1.X.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-patches by date

Next:From: davegDate: 2005-12-31 05:35:20
Subject: Re: TODO item: list prepared queries
Previous:From: Bruce MomjianDate: 2005-12-30 21:44:47
Subject: Re: [BUGS] Solaris cc compiler on amd: PostgreSQL does not have native

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