Re: Improve error handling in pltcl - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Improve error handling in pltcl
Date
Msg-id 56F5AC8D.4080104@BlueTreble.com
Whole thread Raw
In response to Re: Improve error handling in pltcl  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [PATCH] Phrase search ported to 9.6
Next
From: Tom Lane
Date:
Subject: Re: multivariate statistics v14