Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.postgresql > #300 > unrolled thread

User-defined type -- error handling

Back to article view | Back to comp.databases.postgresql

Contents

  User-defined type -- error handling Don Y <this@isnotme.com> - 2012-02-12 11:29 -0700
    Re: User-defined type -- error handling Jasen Betts <jasen@xnet.co.nz> - 2012-02-13 09:20 +0000
      Re: User-defined type -- error handling Don Y <this@isnotme.com> - 2012-02-14 20:53 -0700

#300 — User-defined type -- error handling

Hi,

I have a few types that aren't economically supported in
PostgreSQL that I'll be implementing as "user-defined
types" (NOT "composite types").  Some of this is to
enforce particular semantics (that PG doesn't currently
support in the data model most appropriate to the
application domain).  But there are also efficiency
issues (caching "expensive" characteristics *in* the
object itself).

I like to code defensively.  Lots of invariants in the
code, etc.  I.e., if it *CAN'T HAPPEN*, then I can
explicitly enforce that:
      ASSERT(cant_happen, "The impossible HAS happened!")

Of course, I can't bring PostgreSQL to its knees if something
like this *does* happen (an indication of a bug *somewhere*,
no doubt -- in the type itself, the implementation, the data
model, constraints, etc.).

So, I'm trying to figure out what error to throw and how
PG will react in that event (i.e., just abort the transaction?)

[Note that such errors can be thrown by any of the code that
accesses/implements/modifies the type's representation.
So, they can appear in updates, queries, etc.]

Thanks!
--don

[toc] | [next] | [standalone]

#302

On 2012-02-12, Don Y <this@isnotme.com> wrote:
> Hi,

> So, I'm trying to figure out what error to throw and how
> PG will react in that event (i.e., just abort the transaction?)

22000 looks like good starting place unless one of the other 22xxx
errors fits better

http://www.postgresql.org/docs/9.1/static/errcodes-appendix.html

yes, it will abort transaction much like "select 1/0;" does.



-- 
⚂⚃ 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#307

Hi Jasen,

On 2/13/2012 2:20 AM, Jasen Betts wrote:
> On 2012-02-12, Don Y<this@isnotme.com>  wrote:

>> So, I'm trying to figure out what error to throw and how
>> PG will react in that event (i.e., just abort the transaction?)
>
> 22000 looks like good starting place unless one of the other 22xxx
> errors fits better
>
> http://www.postgresql.org/docs/9.1/static/errcodes-appendix.html
>
> yes, it will abort transaction much like "select 1/0;" does.

I'm thinking of how I would be able to figure out *where*
this was biting me and how I could *fix* it, once bitten.

E.g., imagine having an assertion fail in the "out()" function.
You couldn't *see* the values that were giving those problems
(even if you could identify the rows that were involved).

I've got to stew on this a bit longer...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.databases.postgresql

csiph-web