On Sat, Jul 03, 2004 at 11:17:18AM +1200, Oliver Jowett wrote:
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.
Almost. But prepared statements can break compatibility with code not
aware of their existence yet--and in some cases, this does not happen if
they behave transactionally. It may not be a big deal, but I'm not
convinced that the effort of supporting rollbacks in middleware is such
a big waste of time either.
I stand by my original statement: making no change does not break compatibility. Please provide an example of PREPARE/EXECUTE use that works under 7.3/7.4 but does not work with current 7.5.
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.
But neither of these pose as SQL statements. It's the SQL session that
I'm really worried about.
Parse/Bind/Execute interact with PREPARE/EXECUTE -- they share a namespace. Quirky as the current behaviour is, it'd be even quirkier if PREPARE/EXECUTE had substantially different semantics to Parse/Bind/Execute.
Please do read the V3 protocol spec: http://developer.postgresql.org/docs/postgres/protocol.html
-O
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
