Message-ID: <47FF1605.8050301@postnewspapers.com.au>
Date: Fri, 11 Apr 2008 15:40:53 +0800
From: Craig Ringer <craig@postnewspapers.com.au>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Erik Jones <erik@myemma.com>
Cc: "pgsql-sql@postgresql.org List" <pgsql-sql@postgresql.org>
Subject: Re: Testing for null record in plpgsql
References: <491AB2F3-6ACF-4D58-A195-9D7A848E479A@myemma.com>
In-Reply-To: <491AB2F3-6ACF-4D58-A195-9D7A848E479A@myemma.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Erik Jones wrote:
> Now, let's say I want to call this from another function and test the 
> result to see if I have a null record (null, null),.  I've got the 
> following working but it feels like there should be something much 
> simpler but I just can't seem to hit on it.  Is this it?
I'm assuming that returns_null_maybe() is  a dummy to show general 
behavior. I can't imagine why you'd ever want to do what it's doing.

In general I'm suspicious of code that's testing for a real, known value 
and returning NULL in its place. It seems like an odd thing to do. 
Still, I'm sure you have your reasons and they probably make sense in 
the real application rather than the simplified example.

You can tidy test_null_rec a little by just using:

RETURN row(res.*) IS DISTINCT FROM row(null_rec.*);

but otherwise, without incorporating it into the containing query as a 
subquery I don't see much to be done. I'm still curious about the 
purpose of using null values like this is, though.

--
Craig Ringer