Re: Can the backend return more than one error message per PQexec?
От | Peter Eisentraut |
---|---|
Тема | Re: Can the backend return more than one error message per PQexec? |
Дата | |
Msg-id | Pine.LNX.4.30.0106061649160.757-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Can the backend return more than one error message per PQexec? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Can the backend return more than one error message per PQexec?
|
Список | pgsql-hackers |
Tom Lane writes: > Since there will always be asynchronous conditions to deal with, it'd > be pretty foolish to design a protocol that assumes that exactly one > 'E' message will arrive during a PQexec cycle. Reasonable. > > I am currently looking into extending the protocol so that more fields can > > be in an ErrorResponse (e.g., error codes). If this were to happen then > > we'd need a smarter way of handling more than one error message per cycle. > > Only if you want to overload ErrorResponse so that successive 'E' > messages mean different things. I do not think that would be a good > design. It'd be better to allow ErrorResponse to carry multiple fields. That's the idea. But I can hardly concatenate the error codes, can I? I looks as though we need an API where all the messages (errors + notices) from each query cycle are collected and can be cycled through after completion. > This'd imply a protocol version bump, but so what? Changing the > semantics of ErrorResponse probably ought to require that anyway. I think I could have done with a minor bump, but if you have some plans, too, the easier. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
В списке pgsql-hackers по дате отправления: