Re: statement logging / extended query protocol issues

Oliver Jowett wrote:
> Bruce Momjian wrote:
> 
> > Well, from the application writer perspective, you are right it doesn't
> > make sense,
> 
> This is exactly what the end user is going to say.
> 
> > but this is only because jdbc is using prepare internally. 
> 
> Isn't this mostly irrelevant to the result we want to see? It's a detail
> of how the interface layer chooses to execute its queries, and 90% of
> the time the end user is not going to know or care about it.

Right, but have no way to know if the user is using an interface that
hides prepares from them, or they are using prepares visibly in their
applications.  For this reason, we should just display whatever the
backend is doing.  If all interfaces used prepares invisibly like jdbc,
we would be right to suppress the log information.

> > If you were to have written it in libpq, it would make sense, I think,
> > and internally, this is what is happening.  We can't assume only
> > interface libraries like jdbc are using this feature.
> 
> Wait, so is the extended query protocol the poor cousin of "what libpq
> does", or what? You can do Parse/Bind using libpq, can't you?

Sure.

> The *meaning* of the Parse/Bind/Execute sequence is quite clear
> regardless of what interface library is used. I still think that logging
> just the queries that were actually executed, once per execution, is the
> sensible thing to do here. I can't see a sequence of protocol messages
> that would produce a strange result if we used the rules I suggested --
> do you have an example where it breaks?

I have no idea.

> > As far as I understand things, the protocol-level prepare/execute is
> > identical to the SQL-level prepare/execute, except that there is no need
> > to parse the execute, so it should log like the SQL-level statements, if
> > possible.
> 
> You can Parse any SQL statement, but you can't PREPARE any SQL
> statement. So, no, they're not equivalent. That's one aspect of what I
> meant about generating synthetic statements that weren't syntactially
> correct (the strange FETCH syntax with ROWS/MAXROWS that Simon was
> suggesting is another case).

I am hesitant to add another log syntax to be used just for
protocol-level prepare.  I think it adds complexity with little benefit,
particularly for people reading those logs with automated tools.

Simon's page is in the patches queue.  What would you like changed,
exactly?

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