Re: Extending a bit string

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

In response to

Browse pgsql-hackers by date

  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