Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA17729; Tue, 18 Feb 92 11:52:34 -0800
Message-Id: <9202181952.AA17729@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: NULL pointers in ADTs
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Tue, 18 Feb 92 18:28:26 +0700."
             <9202181724.AA15021@postgres.Berkeley.EDU> 
Date: Tue, 18 Feb 92 11:52:20 PST

you write:
>Dear Postgres-group,

>There is a problem with the return of NULL pointers in ADTs.
>I'm working on the implementation of some 3D data types: POINT3, BOX3, etc.
>I have implemented one function for calculation the intersection of
>two boxes.

>In case the intersection is empty, this function returns NULL
>(similar to the standard Postgres function for the intersection of
>two 2D boxes). The function works fine as long as there is a non empty
>intersection of the BOX3es.

>Ok, so far so good. Now I insert a new BOX3 that does not have overlap
>with the others

>The last query causes the monitor to loop forever (until ^C). This is caused
>by the return of the NULL pointer in the situation that there is no overlap.
>I could put an "elog(WARN, "No intersection BOX3 BOX3");" statement in
>my code for Intersect3BoxBox (as suggested some time ago on the Postgres BBS).
>However, this causes the transaction to abort and will therefore not give
>any answers

>By the way, this problem also applies to all the "standard" Postgres
>functions that return NULL pointers (as the original 2D box intersection
>function: box_intersect in /usr/postgres/src/utils/adt/geo-ops.c).

>Another aspect of this problem is that the Intersect3BoxBox function
>will also be used for the 3D R-tree. Other functions within Postgres 
>which are used to manipulate the R-tree need the Intersect3BoxBox function.
>These functions can explicitly deal with the NULL-pointer return.
>However, aborting the transaction (through a call to elog(WARN,"...");)
>would be wrong in this situation.

You are right on all counts.  The problem is that postgres does not handle
null (attribute) values very well.  When a pass by reference ADT input or 
manipulation function (a function that returns a pass by reference ADT) 
returns NULL, POSTGRES will lay an egg.  If the ADT is passbyvalue
POSTGRES will interpret it as the value 0.  In general you can't assume that
0 will always mean null when you are doing ADT processing.

>Is there a more elegant solution for this NULL-pointer problem?

The solution is to require all ADT input and registered functions to
accept an isnull boolean ptr as their first argument.  This way the executor
can know if it is receiving a null result and handle it accordingly.  
Unfortunately, when I suggested that we implement this for version 4 people 
(who are already overburdened) threw large objects (no pun intended) at me.
It is likely that this will be implemented in a 4.1 (bug fix) release.  For 
now you will have to live with the ugliness as best you can.


Jeff Meredith
mer@postgres.berkeley.edu