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" <[EMAIL PROTECTED]> 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 > ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
