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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
