Re: Nested Transaction TODO list
От | Tom Lane |
---|---|
Тема | Re: Nested Transaction TODO list |
Дата | |
Msg-id | 21364.1088872228@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Nested Transaction TODO list (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
Ответы |
Re: Nested Transaction TODO list
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@dcc.uchile.cl> 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
В списке pgsql-hackers по дате отправления: