From: | Evan Carroll <me(at)evancarroll(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Extending a bit string |
Date: | 2018-04-24 15:59:14 |
Message-ID: | CAAiePB4Z52yC7hNNB4n6mi2VyGZWV9ZYN4vd+YfAc3etutxq_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> That's SQL:99 6.22 <cast specification> general rule 11) c).
> (SV and TD are the source value and the target datatype for a cast.)
>
> In hindsight, it would likely be more consistent with this if we'd
> considered bitstrings to be LSB first when coercing them to/from integer,
> but whoever stuck that behavior in didn't think about it. Too late to
> change that now I'm afraid, though perhaps we could provide non-cast
> conversion functions that act that way.
>
Apologies, I was under the impression that casts were not in the spec. I
withdraw my request. In the 2016-draft it reads,
> If the length in octets M of SV is smaller than LTD, then TV is SV
extended on the right by
LTD–M X'00's.
That's how I read it too, and whether I feel like it's insane doesn't
matter much. But yet, the idea
5:bit(8)::bit(32)::int
Not being 5 is terrifying, so you won't find any objections to the current
behavior from me.
--
Evan Carroll - me(at)evancarroll(dot)com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2018-04-24 16:06:44 | Re: Corrupted btree index on HEAD because of covering indexes |
Previous Message | Peter Eisentraut | 2018-04-24 15:49:25 | Re: Bugs in TOAST handling, OID assignment and redo recovery |