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


Groups > comp.databases.postgresql > #300

User-defined type -- error handling

From Don Y <this@isnotme.com>
Newsgroups comp.databases.postgresql
Subject User-defined type -- error handling
Date 2012-02-12 11:29 -0700
Organization Aioe.org NNTP Server
Message-ID <jh90df$435$1@speranza.aioe.org> (permalink)

Show all headers | View raw


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

Back to comp.databases.postgresql | Previous | NextNext in thread | Find similar


Thread

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

csiph-web