Re: using functions to generate custom error messages - Mailing list pgsql-novice
From | Joel Rodrigues |
---|---|
Subject | Re: using functions to generate custom error messages |
Date | |
Msg-id | 83E95DA3-F9EF-11D6-A592-0005024EF27F@Phreaker.net Whole thread Raw |
In response to | Re: using functions to generate custom error messages (Rod Kreisler <rod@23net.net>) |
List | pgsql-novice |
Hi, The whole business of 'portability' as usually tossed around is highly suspect. One could argue that having as much as application logic as possible in one's carefully considered and chosen DBMS makes for a very portable application. It easily accommodates, as Rod says, multiple front ends under different platforms, with very little coding required of the developers of those front ends. I also agree that data integrity constraints should be in the DBMS itself. Well, 'reasonable' is good. I've just got to come up with a way to keep track of all the functions & triggers. I just wish Trigger Functions would accept arguments. Something for a future revision of PostgreSQL ? Tchau, Joel Rodrigues On Saturday, November 16, 2002, at 07:32 , Rod Kreisler wrote: > 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.
pgsql-novice by date: