From: "Janning Vygen" <vygen@planwerk6.de>
> one of my problems:
> if i have a value like bool or int2 and the frontend is html and just
takes
> the input from a textfield, the backend returns an error before executing
the
> trigger beacuse the values cant be parsed into the correct type.
>
> But should not the trigger be called BEFORE inserting?
> It seems not, maybe just because the NEW record has to be filled and with
a
> mismatching type it can't be done!?
Correct - your update/insert statement will be parsed before it gets
processed. It's only if the statement passes the checks and gets executed
that your trigger will see it.
> Bad thing about it: my trigger should report every error. but it is never
> executed when the type parsing fails.
>
> I just dont want to put any error handling code in my frontend. I just
want
> the backend to return something like
> "ERROR: errormessage1; ERROR: errormessage2;"
> to return all errors on all fields.
Data validation (making sure all values submitted are of valid types and
ranges) needs to be done before you reach the database. You should be
checking all submitted values anyway, just for security implications. Do
this in your server-side Perl/PHP/Java/C, don't just rely on javascript in
the browser.
Only allowing users to add orders for products with an existing
product-code, now that is something that can (and should) be enforced in the
database. Personally, I'd still want to trap the errors from the database
and then produce a user-friendly message in my application.
> Can anybody tell me how to make a really good and flexible error
processing
> with postgreSQL??
Examine the types of errors that can occur. You should find they fall into a
number of different classes. These classes should (hopefully) closely match
the structure of your application. Each part of your application should then
be responsible for generating its own exceptions and dealing with errors
generated by helper modules.
In your case, handle this in your object/database abstraction layer. If you
don't have one, build one - it's not usually a big issue performance-wise
and will pay you back tenfold if you need to change the underlying database
/ database system.
HTH
- Richard Huxton
