fix: expose is_invalid to avoid panic if the logical type is invalid

[rubenfiszel]

We got quite burned by this for queries where id() would just panic.
Example of a query that would panic:

select Date,Env from read_csv($file);

with csv:

Date,Env
"foo","bar"

and us running:

                            (0..stmt.column_count())
                                .map(|i| {
                                    let logical_type = stmt.column_logical_type(i);
                                    if logical_type.is_invalid() {
                                        None
                                    } else {
                                        logical_type.get_alias()
                                    }
                                })
                                .collect::<Vec<

on first row (note that i'm using is_invalid here and otherwise we would have fetched get_alias directly and got a panic

[diegoimbert]

I'd add that I think that the real problem is that invalid logical type id shouldn't be returned from that query, but it's still nice to be able to check if the id is valid for worst case scenario

[mlafeldt]

Thanks for the PR!

I took a look at the underlying problem and think that #629 would be a better fix that also addresses your particular needs. Do you agree?

[rubenfiszel]

Yes I agree that would also work but I would still argue that the semantic of having panic there seems wrong. It should be an unreachable! if it's truly unreachable after that change.

[mlafeldt]

Good point. I changed LogicalTypeId to be non_exhaustive and return a new "unsupported" value. There's also a new try_id helper.

PTAL: #629