Kris Jurka wrote:
> I was looking at the assorted changes to the PGobject extensions and I'm
> unclear on exactly how NULL is handled. Consider PGmoney has tests for
> NULL in equals, clone, and getValue, but PGbox does not. Is this simply
> an oversight or is there something more profound going on here.
I ended up with two approaches for this.
For those types where there was already a field I could hijack to
represent NULL -- e.g. PGbox's points array -- I used that to represent
null values. The singleton NULL is just a normal object that happens to
have a null value. You can have several different objects that all
represent null if you like, and you can mutate an object representing a
null value just like any other object of the type. This is consistent
with the way other instances of the type operate, but it's slightly
dangerous as it's possible to modify the NULL singleton so it no longer
has a null value (pity we don't have 'const'..)
For the other types that didn't have a suitable field, I'd have needed
to add a field to every instance of the type to indicate whether the
object was a null or not. Instead, I used the identity of the NULL
singleton to decide when an object is null. In that case, there is only
ever one object that represents a null, and the actual value it holds is
irrelevant -- getValue() etc. check the identity of 'this' before
looking at the actual value.
It's hardly ideal but it kept the changes to a minimum. If you don't
mind a more invasive set of changes, I can probably come up with
something better.
-O