Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Sat, Jul 03, 2004 at 11:03:33AM -0400, Tom Lane wrote:
>> What about reporting transaction state/nesting level to client? I did not
>> like the GUC-variable approach in the original patch, partly on grounds of
>> efficiency and partly because I doubt it works under transaction-failure
>> conditions. I'm inclined to think we need a small protocol change.
>> Perhaps it would work to add an additional field to Z messages that is
>> only sent when nest level > 1.
> It's a shame to have to lose backwards compatibility.
I don't like using ParameterStatus because it's not designed for dealing
with values that may change many times in a single query. Also it sends
strings, which this really isn't.
I haven't looked at JDBC, but at least in the libpq code, what we could
safely do is extend the existing no transaction/in transaction/in failed
transaction field to provide a five-way distinction: those three cases
plus in subtransaction/in failed subtransaction. You could not directly
tell the depth of your subxact from this, but do you need to?
regards, tom lane
---------------------------(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
