Re: log_statement and Parse/Bind

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: log_statement and Parse/Bind
Date: 2004-05-25 02:39:54
Message-ID: 200405250239.i4P2dsR25902@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Oliver Jowett wrote:
> I notice that when using the extended query protocol, statement logging
> appears to happen only when a Parse message is received. This is less
> than ideal:
>
> - statements can be logged that are not actually executed (i.e. a
> Parse/Bind with no corresponding Execute).
> - if statements are re-executed without an intervening Parse (i.e.
> Parse/Bind/Execute/Bind/Execute/...), only the first execution is logged.
>
> There's also a lesser problem with using parameterized queries: the
> actual parameter values used in a Bind are not visible. This is the same
> as the PREPARE/EXECUTE case, except that it's more likely to be done
> transparently by the client's interface library (so we can't just tell
> the application developer "don't do that, then!")
>
> Are there any plans to change this? Should I look at making a change
> along the lines of logging the statement on the first Execute of a
> portal, instead of on Parse?

Well, at execute time, we don't have easy access to the original prepare
statement, especially at that stage in the code. Do you see anyway to
improve that?

--
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-05-25 02:43:17 Re: New horology failure
Previous Message Tom Lane 2004-05-25 02:29:13 Re: New horology failure