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 по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: [PATCH] Phrase search ported to 9.6
Следующее
От: Tom Lane
Дата:
Сообщение: Re: multivariate statistics v14