Jeroen T. Vermeulen wrote:
Just don't tell me that making PREPARE respect rollbacks would break compatibility
Why not? It's true.
So many things are true. But _not_ doing so also breaks compatibility,
so like I said, there are counterexamples.
This is nonsense. Not changing the current behaviour cannot break compatibility, almost by definition.
Also: what about the V3 protocol's support for named statements?
Haven't looked at them (I work on top of libpq),
Please do take a look. The V3 protocol treats the set of named statements as part of the connection state, not as anything at the SQL statement level. There are also named portals to deal with if your issue is that things shouldn't be named.
So again, I'd like to hear any comments about my pattern-matching proposal. Is there any problem here that it would not solve? Does anyone see a problem in implementing them?
The client has query-lifetime and query-reuse information that the server does not have and can't obtain via simple query matching. Also, clients need per-query control over use of PREPARE: prepared queries can run slower as they must use a more general query plan. I don't see how you overcome either of these if the server hides the mechanics of which query plans are preserved.
You could implement the pattern-matching logic as a passthrough layer in front of the server -- perhaps in something like pgpool? -- and translate to PREPARE based on patterns. Then your application can remain unaware of the translation to PREPARE for the most part, the only issue being name collision which in practice is simple to work around. But I don't see why you want this in the main server at all -- it's really a bandaid for applications that don't want to precisely control the prepared-statement behaviour themselves.
-O
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
