Skip site navigation (1) Skip section navigation (2)

Re: using functions to generate custom error messages

From: "Josh Berkus" <josh(at)agliodbs(dot)com>
To: Joel Rodrigues <skyfyre(at)Phreaker(dot)net>,pgsql-novice(at)postgresql(dot)org
Subject: Re: using functions to generate custom error messages
Date: 2002-11-15 17:53:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice

> Would it be considered good practice to use functions to generate
> custom error messages ?

Depends on what you mean by "good practice".   The "best practice",
arguably,  would be to do this in some kind of middleware.   If,
however, your project is too lightweight to have middleware, then using
functions to do so can be pretty good.

An alternate, perhaps much simpler approach, would be to intercept the
database error messages and transform them into custom error messages
through text parsing or an error lookup table.

> The only odd thing about it I can see is that constraints have to be
> coded into the function, whether or not they've already been included
> in the table itself.

Absolutely.  In fact, if you take this approach, you might drop the
table constraints as redundant -- provided that you manage your
checking functions well.

> I do understand that there are other ways/places to do error
> checking, in the CGI script or in JavaScript, but this is how/where
> I'd like to do it.

Absolutety.  The drawbacks to this approach, however, are:
1) managing all these testing triggers
2) performance loss if the triggers are significantly slower than

> BTW, does anyone know why \df doesn't find the function "maxten" that
> I created ?

Currently, \df does not list any function which returns OPAQUE.  I'm
not sure of the reason for this.

-Josh Berkus

In response to


pgsql-novice by date

Next:From: Tom LaneDate: 2002-11-15 22:01:17
Subject: Re: Question on locale settings
Previous:From: Bruno Wolff IIIDate: 2002-11-15 17:29:03
Subject: Re: Efficiency of stored procedure vs large join

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group