I am not suggesting that all functions or operators work this way, because I
believe the current implementation is more standard. I would like to be
able to over ride this default behavior and change a NULL value into return
value. A great example of this is the Access function nz(int_value). If
int_value is null, nz() returns 0, it is it not null then int_value is
returned. I used this function frequently in Access and would like to take
advantage of this in PostgreSQL.
Thanks, Michael
-----Original Message-----From: Clark Evans [SMTP:clark.evans@manhattanproject.com]Sent: Tuesday, March 16, 1999
4:23PMTo: Michael DavisCc: hackers@postgreSQL.orgSubject: Re: [HACKERS] Associative Operators? (Was: Re:
[NOVICE] Out of frying pan, into fire)
Michael Davis wrote:> Speaking of this, If either LASTNAME or FIRSTNAME is NULL then the
result of> ((LASTNAME || ',' ) || FIRSTNAME) will return NULL. I would like
to be able> to alter this such that the result will contain what ever is not
NULL. I> tried to create a C function to overcome this but noticed that if
any> parameter in my C function is NULL then the C function always
returns NULL.> I saw some references in the archives about this issue but was
unable to> determine where it was left. What is the status of this issue?
Although I feel initial opposition to this idea, on second consideration, I guess it is reasonable behavior, in
Oracle,the NVL function and the DECODE function both handle NULL arguments without having the result be NULL.
However, I'm unaware of any other exceptions in the Oracledatabase on this issue. I believe that user defined
functionsare not allowed to have special NULL treatment -- perhaps Oracle has DECODE and NVL hard coded deep in the
gutsof their query processor, while the other functions arn't.
Would a compromise be to add DECODE and NVL ?
Clark