Postgres: unsupported type BIT of column

[letto4135]

Hello,

It seems that Postgres doesn't support the BIT type, I found a closed issue for mssql however the solution doesn't work for my case as they seem to assume it is always going to be bit(1). The database I am attempting to use has a bit(1500) that should probably be read as a String... Other solutions I've seen have been to write out every column I want instead of * which seems more of a nuisance than it should be. Anyone happen to know any other solutions?

Example of the columns data is
100000000000000000011000000010100000000000000000100100100000000000000000010000000000000001000000000000000001000100000000000000000000000100000000000000000100000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000010001000000000000000000000000000000000000000000000000000000000001000000000000010000000000000000000000000000000000010000010000000000000000000000000000000000010100000001000001000000000000000000100000001000000000000000000000000001001100000000000000000000000000000000000000000000000000000000000000000000000000000000000011100000000000010000001000000010000010000000100000000000000000000001101001000000000010000000010100001000000000000001000000100100000000010000000000000000000110110000000000000000000000000000000000000000000000001000000000000000000101000000000100000010000000000000001000000000000000000001000000010100000000000000000000100000000000000100000110001000000010001000000100000000000010110000100000000100010100010100001000010001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

[letto4135]

I'm also having issues with the Geography type... Would it be possible to read unknown types as strings and log a warning instead of throwing exceptions maybe?

[jplatte]

Does SELECT column::TEXT FROM table WHERE … do what you want?

[letto4135]

@jplatte yeah I can cast the columns but I'm trying to avoid a mile long sql query having to select each individual column if it's an easy fix lol

[abonander]

The design of SQLx is intended to push you to think about the data you actually need at a given query site, rather than wielding SELECT * like a club. You do end up writing more queries but it gets easier and easier as you get more familiar with SQL, and has the advantage of being more efficient as you stop requesting data that you don't actually need.

But there's also 2-3 orthogonal issues here:

• Should we support the BIT type? I think yes. But what should it map to?
  • Vec<bool>? It has the advantage of only using standard types and being intuitive to address but is very inefficient.
  • Packed in a Vec<u8>? More efficient but harder to address individual bits, would also need a separate length field
    if the returned bitstring length isn't a multiple of 8.
  • A custom type wrapping Vec<u8> and providing bit-level addressing? That would work, but why do that when:
  • We could use some type from the bitvec crate, but which one? Perhaps bitvec::boxed::BitBox?
• Should we fall back to text format for unknown types and deserialize as String?
  • We don't currently have a way to tell the connection which types should be binary and which should be text;
    it assumes either all binary or all text depending on whether we're using a prepared statement or not.
    That could be fixed, of course, but:
  • It could be even more confusing than an "unknown type" error, especially when involving types that are only supported
    under feature flags. We already have checks for that, true, but the semantics could get complex.
• Should we support PostGIS types? Yes, but we already have an issue for that, which you seem to have found already: Postgis location types #1361 (comment)

[letto4135]

I like wielding clubs :D
So, what I'm making an attempt at is rewriting an API in Rust, and part of the issue is that all of the columns are returned in the response around 75% of the time, the other 25% SQL queries are constructed to fit the bill, but it's hard to justify having yet another place to change code whenever a new column is added that needs to be returned, which unfortunately is more often than it should be, but that's just the nature of the type of data...

BitBox looks interesting to me, and possibly more efficient than Vec? The bits should be addressable individually I think and the complexity that Vec adds to that I think it would be good to rule it out...

Adding complexity isn't something I'm a fan of, Rust is complicated enough for me at this point... Would it really be more confusing than unknown type? Or would it be more confusing than unknown type for those that are ignoring warning messages? I think it depends on how many unsupported types there are possibly... If there has to be another 600 issues opened before all types are officially supported then it's probably good to have a fallback, at least then people can manipulate it after they have the data if they want to instead of requiring a fix for it.

Thanks for taking an interest in the issue. This is my first project in Rust other than just dorking around with little scripts to see what's what, so not real comfortable contributing yet, but if this is still around in a bit I'll try and take a stab at it.