From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gerald Luger <GeraldLuger(at)hexboss(dot)com> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #8191: Wrong bit conversion |
Date: | 2013-06-01 04:27:38 |
Message-ID: | 14954.1370060858@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Gerald Luger <GeraldLuger(at)hexboss(dot)com> writes:
> Shouldn't I expect all results to be 000...0001?
Well, no.
The SQL spec is pretty clear about the interpretation of this:
b'1'::bit(64)
You're taking a bit string of length 1 and casting it to bit string
of length 64. That's done by appending zeroes on the right, per spec.
The x'1' notation isn't in SQL99 AFAICS, but we consider that x'1'
means the same as b'0001', and then the conversion from bit(4) to
bit(64) is done by padding zeroes on the right.
Your last case,
1::bit(64)
represents casting an integer to bit(64). This operation isn't in the
SQL spec either, unless I missed something. We treat this as conversion
of the integer's twos-complement representation to a bit string,
presuming big-endian representation of the integer.
Now you can quibble with various of the details above, but in the end
they are all arbitrary decisions. We've made them that way, and it
would take a pretty impressive argument to persuade us to break existing
applications by changing them.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2013-06-01 04:33:08 | Re: [BUGS] BUG #8177: initscript should create /var/run/postgresql |
Previous Message | John R Pierce | 2013-06-01 04:26:10 | Re: BUG #8191: Wrong bit conversion |