commit 92fcf9360bda2db0be1c00145cd02ac4b055252a
author Sean Griffin <sean@seantheprogrammer.com> Tue Jul 10 15:58:54 2018 -0600
committer Sean Griffin <sean@seantheprogrammer.com> Mon Jul 30 11:46:21 2018 -0600
tree c68dcaa65c4424229b425fb8d05ba181a16e56d9
parent aecc3777c74ede46d95b96e8a52caf0559be6aa1

Allow arrays with a non-zero lower bound

When I originally implemented support for arrays, I didn't really
understand what `lower_bound` was, and observed it was always 1. For
that reason, I added the assertion that it must be 1 since I didn't know
if our behavior was correct when it was some number other than 1 (at the
time I thought it was related to multidimensional arrays)

So it turns out that it's literally just the index of the first element
of the array. For whatever reason, PG arrays are 1 indexed by default,
and they have a syntax which lets you have arrays starting at *any*
index. Knowing this, we can safely ignore it.

We will continue to give you a zero indexed `Vec` regardless of what the
lower bound is, since the only other alternative would be to always
deserialize to `Vec<Option<T>>`. If we did this, it would mean that
`ARRAY[1, 2, 3]` would deserialize to `vec![None, Some(1), Some(2),
Some(3)]`. While this is technically more faithful to what PG gives us,
I don't think anybody expects that behavior.