Re: [HACKERS] NULL handling question

From: "D'Arcy" "J(dot)M(dot)" Cain <darcy(at)druid(dot)net>
To: lockhart(at)alumni(dot)caltech(dot)edu (Thomas Lockhart)
Cc: neko(at)kornel(dot)szif(dot)hu, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] NULL handling question
Date: 1999-03-29 17:27:05
Message-ID: m10RfoX-0000c3C@druid.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thus spake Thomas Lockhart
> > I don't seek this in the source, but i think, all function, who take a
> > NULL value as parameter can't return with a NOT NULL value.
> > But why?
>
> Postgres assumes that a NULL input will give a NULL output, and never
> calls your routine at all. Since NULL means "don't know", there is a

Actually, the problem is that it does call the function. After it
returns it throws away the result and so the effect is that the function
never gets called but in the meantime, the function has to deal with
NULL inputs for nothing. This has been hanging around since the last
release. I looked at the dispatch code but it wasn't very clear where
we have to put the test to do this correctly. Maybe we can get it cleaned
up before release this time.

> strong argument that this is correct behavior.

I agree but recently I said that there was no stored procedures in PostgreSQL
and someone corrected me pointing out that functions with no return were
in effect stored procedures. Do the same arguments apply? If a procedure
is passed a NULL argument, should the side effects be bypassed?

--
D'Arcy J.M. Cain <darcy(at){druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 1999-03-29 17:28:34 Re: [HACKERS] Speedup idea: avoid using SQL procedures as aliases
Previous Message Edmund Mergl 1999-03-29 17:19:50 Re: [HACKERS] Large objects error - expected a 'V' from the backend