RE: [HACKERS] PL/pgSQL a great procedural language for PostgreSQL - Mailing list pgsql-hackers

From Jackson, DeJuan
Subject RE: [HACKERS] PL/pgSQL a great procedural language for PostgreSQL
Date
Msg-id F10BB1FAF801D111829B0060971D839F4D735E@cpsmail
Whole thread Raw
Responses Re: [HACKERS] PL/pgSQL a great procedural language for PostgreSQL
List pgsql-hackers
> > It appears that when a function is called if any of the paramaters
> are
> > NULL all of the parameters are NULL.
> > try:
> >  drop function nvl(int, int);
> >  create function nvl(int, int) returns boolean as '
> >   declare
> >     nonullo alias as $1;
> >     nullo alias as $2;
> >   begin
> >    return (nonullo IS NULL) AND (nullo IS NULL);
> >   end;' language 'plpgsql';
> >  select nvl(i,0) from a;
> > you should get:
> > nvl
> > ---
> > t
> > t
> > f
> > t
> > (4 rows)
> 
>     Don't blame PL/pgSQL for that.  There is only one bool isNull
>     pointer given to PL handlers. How should the PL handler know,
>     which  of  the arguments are null then?  As I said on another
>     thread, the function call interface needs to get  redesigned.
Well, Jan, don't get sensitive.  I love PL/pgSQL. And I had no illusions
that it was your HANDLER causing the problem.  I feel that a function
call interface redesign is also needed.  But, I do have a quick
question, why does it matter which one is NULL if you can still obtain
the parameters in the order they were passed why would one become NULL
that wasn't before?   I'm asking totally from ignorance here.-DEJ

> Jan
> 


pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: [HACKERS] problem with latest snapshot
Next
From: "Jackson, DeJuan"
Date:
Subject: RE: [HACKERS] Re: bug on aggregate function AVG()