Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.databases.postgresql > #300
| 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) |
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 | Next — Next in thread | Find similar
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