David Anthoff

> I don't think so, since `NullableArray` is not itself a `Nullable` type. So `==(X::NullableArray, Y::NullableArray)` should return a Bool, whereas I think legitimate cases have been made for returning...

> Yes, ==(::DataFrame, ::DataFrame) would also have to return a Nullable{Bool}, which requires some tweaking. I see why having `==(::Nullable,::Nullable)` return a `Nullable{Bool}` can sometimes be useful (although I think...

Yeah, but checking results might be quite a common and useful thing? I don't know, you load data and manipulate data in some way (via Query.jl or jplyr.jl), and then...

Just to note that this won't work in Query. I need proper predicates in Query that return ``Bool``, not ``Nullable{Bool}``, so Query will just opt out of the whole ``Nullable``...

That is actually something that should work in the julia VS Code extension.

Yes, I'm sure that could help a lot! PRs welcome.

Ah, super interesting! DoubleFloat.jl is quite key for the float parsing in TextParse.jl. And float parsing in general seems so central that I don't really see how we could remove...

No :) ExcelReaders.jl will still pull it in, but we should be able to remove it here. Do you want to open a PR?

Another thing that would be neat is to be able to specify this separately for different columns. We are planning/thinking a lot about whole query optimization in Query.jl right now,...

I think you are starting this from JuliaDB, right? Could you try whether it works if you stick with just TextParse.jl? Like this: ```julia using TextParse csvread( "/Users/christopheralexander/Documents/testcsv.csv", colparsers=Dict(10=> dateformat"yyyymmdd"),...