Reshat,
You have some points, however just as there is the possibility of switching
RDBMS, there is a possibility that the frontend language will change as
well. Furthermore, a greater possibility, I think, that multiple frontends
under different platforms will access the one data source.
Data integrity constraints MUST be in the database itself anyway (if not,
then I suggest using MySQL...), otherwise you are hoping that multiple ADs
are going to properly maintain integrity in the applications.
IMHO, what Joel suggests is quite reasonable.
Rod
> -----Original Message-----
> From: pgsql-novice-owner@postgresql.org
> [mailto:pgsql-novice-owner@postgresql.org]On Behalf Of Reshat Sabiq
> Sent: Saturday, November 16, 2002 12:55 AM
> To: 'Joel Rodrigues'; pgsql-novice@postgresql.org
> Subject: Re: [NOVICE] using functions to generate custom error messages
>
>
> I think it looks good. But my preference is to keep as little as
> possible in the DB, in case it needs to be moved to a different DB
> vendor's product.
> That way one's CGI or Java can be deployed right off, w/o having to
> re-write stored procedures, etc. And there are real companies out there
> struggling to switch to a different DB because of things like that.
> I am aware of the other extreme: DB admin protects the data and sets
> maximum possible restrictions on access, ADs relying on available stored
> procedures, and limited access. I tend to disagree for portability
> reasons. But if somebody offers a convincing argument in favor of doing
> so, I could change my humble opinion.
>
> My 2 cents,
> r.
>
> -----Original Message-----
> From: pgsql-novice-owner@postgresql.org
> [mailto:pgsql-novice-owner@postgresql.org] On Behalf Of Joel Rodrigues
> Sent: Thursday, November 14, 2002 11:31 PM
> To: pgsql-novice@postgresql.org
> Subject: [NOVICE] using functions to generate custom error messages
>
>
> Hello,
>
> Would it be considered good practice to use functions to
> generate custom error messages ?
>
> 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.
>