This not a killer problem. I'm sure I can find a way around it, but just wanted to provide some more feedback.
We use csv files to move data among heterogeneous systems which unfortunately do not agree on how to represent NULL. Nor do they all put quotes around zero-length strings. H2 has decided that a particular representation of the zero-length string always means NULL. Other systems have decided that the string \N means NULL. Other systems (e.g. Java) have decided that the string null means NULL. There is a certain logic behind each of these decisions. But, bottom line, they are all basically arbitrary. The zero-length string is no more or less special than \N or null. So we need a way to let us make the arbitary decision about what null looks like. Regards. On Thursday, October 3, 2013 5:59:43 PM UTC-4, WillyMac wrote: > > I would expect that the only representation for null would be the one > specified. Maybe it is intended to work this way, but I find it confusing > to have two null representations. Why bother specifying null=xxx if ,, is > read as null anyway? > > Or maybe my syntax is wrong? > > *Input file:* > > c1,c2,c3 > a,,c > a,"",c > a,XX_null_XX,c > > *SQL:* > > select * from > csvread( 'tst.csv', null, 'null=XX_null_XX' ) > > *Output (? == null):* > > C1 C2 C3 > ----------------- ----------------- ----------------- > a ? c > a c > a ? c > > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
