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.
> 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?
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?
> 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).
-O