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

Re: Reducing duplicated business rules

From: Daniel Struck <struck(dot)d(at)retrovirology(dot)lu>
To: Michael Glaesemann <grzm(at)myrealbox(dot)com>
Cc: pgsql-php(at)postgresql(dot)org
Subject: Re: Reducing duplicated business rules
Date: 2003-11-09 15:37:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-php
> Interesting idea. Then you can include more specific information rather 
> than just the PostgreSQL error. I wonder if there wouldn't be a way to 
> use COMMENT information on the constraint as well_grab the COMMENT for 
> whatever named constraint caused it to fail.

I think for normal purposes, the name you can give a constraint should be sufficient.
Else one can think of giving an error number as a name for the constraint and keep the description of the error number in a different table.

> I don't know if this is the best way to do this, but it might be 
> workable in the short term. It would be nice to be able to ask the 
> database, in effect "Okay, yeah, that's not a good piece of data. But 
> let's assume that part were okay. Any other problems? Besides that?" 
> Then you could possibly get more feedback from the database.

True, that would be nice.
Maybe a mode where the database would should all the constraints and not one be one.

By the, this way of handling the format of the data makes your database more independent from a script language. In fact you could use it in perl, java, asp, etc. and don't have to rewrite the whole constraints for submitting data again.


Retrovirology Laboratory Luxembourg
Centre Hospitalier de Luxembourg
4, rue E. Barblé
L-1210 Luxembourg

phone: +352-44116105
fax:   +352-44116113
e-mail: struck(dot)d(at)retrovirology(dot)lu

In response to


pgsql-php by date

Next:From: Daniel StruckDate: 2003-11-09 15:52:28
Subject: client authentication towards postgresql in php?
Previous:From: Patrick WelcheDate: 2003-11-08 23:31:58
Subject: error codes

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