Re: Improve error handling in pltcl
От | Jim Nasby |
---|---|
Тема | Re: Improve error handling in pltcl |
Дата | |
Msg-id | 56F5AC8D.4080104@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Improve error handling in pltcl (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 3/25/16 3:11 PM, Tom Lane wrote: > Jim Nasby <Jim.Nasby@BlueTreble.com> writes: > the data, we're making it unnecessarily hard. All we need is one more > field in there, and you can simplify that to Ahh, nice. > I think actually it's a simple point: there won't ever be a case where > cursorpos is set here, because that's only used for top-level SQL syntax > errors. Anything we are catching would be an internal-query error, so > we might as well not confuse PL/Tcl users with the distinction but just > report internalquery/internalpos as the statement and cursor position. > >> PLy_spi_exception_set simply exposes the raw internalquery and internalpos. > > Right, because that's all that could be useful. Ahh, ok, finally I get it. It would be nice if the comments for ErrorData were clearer... > it strikes me that this is not coding style we want to encourage. > We should borrow the infrastructure plpgsql has for converting > SQLSTATEs into condition names, so that that can be more like Yeah, Karl and I were just talking about that as we were finishing up the docs changes (ironically, as you were commiting this...). I ended up with a more realistic example that also demonstrates that you can refer to errorCode in a separate function if desired. That patch attached for posterity. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
Вложения
В списке pgsql-hackers по дате отправления: