It only does the integer check for numbers of type integer (when # of
decimals = 0), noninteger numbers are not checked in any way. If
isinteger returns 0, the program does give a warning, suggesting it thinks
it detected an illegal field rather than a null field. Contrary to the
isinteger check on dates, which does not give a warning, though it does
enter a null. On dates the check makes sense because dates are always 8
digits long and have no blank padding like numbers. See the spec.
http://www.dbase.com/KnowledgeBase/int/db7_file_fmt.htm
Don't know anything about nulls in dbf though. I am not a dbase expert, I
just run into dbfs often when trying to enter gis data into postgis.
Kind regards,
Boris van Schooten
On Tue, 3 May 2005, Tom Lane wrote:
> "Boris van Schooten" <schooten@cs.utwente.nl> writes:
> > As it turns out, the integer checking code (contrib/dbase/dbf2pg.c, function
> > isinteger) is broken. It appears the function reports 0 in case it finds a
> > space in the dbf rather than a digit. I disabled it (always made it return
> > 1). Now, my dbf files import fine.
>
> Hmm. I know nothing about dbase ... but if the test has any use at all,
> I guess it must be to handle NULL values. How does dbase represent a
> NULL? Why is this code only checking this for integer columns?
>
> regards, tom lane
>
