Re: using functions to generate custom error messages

On Friday, November 15, 2002, at 11:23 , Josh Berkus wrote:

> Joel,
>
>> 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.

This is an interesting suggestion. Perhaps I could do something
with it. Pity that "Trigger Functions" don't accept arguments,
becoming reusable like regular functions.

>> 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.

A bit scary, this bit.


>> 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

Yes !

> 2) performance loss if the triggers are significantly slower than
> constraints.
I don't see this as a problem for my particular application.


>> 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.

Weird thing this. Shouldn't there be a simple command like
"\duf" or something to simply display user created functions
along with their associated tables ?


Overall it seems to me that we have missing mechanism to deal
with this situation. The alternatives appear to be redundant
code, excessive code, or unnecessary code in "middleware".

> -Josh Berkus