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