From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Kevin Brannen <kevinb(at)nurseamerica(dot)net> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: bit field changes in 7.2.1 |
Date: | 2002-07-07 10:59:13 |
Message-ID: | Pine.LNX.4.44.0207070003530.929-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Kevin Brannen writes:
> EXCEPT that now fails in 7.2.1 (I just upgraded this afternoon). It
> forces me to use "b'000000'" instead of "b'0'::bit(6)".
Which is a problem why?
> Searching thru the docs, I find a note that says:
>
> ---
> Note: Prior to PostgreSQL 7.2, BIT type data was zero-padded on the
> right. This was changed to comply with the SQL standard. To implement
> zero-padded bit strings, a combination of the concatenation operator and
> the substring function can be used.
> ---
>
> Obviously the source of my problem. However, whoever wrote that note
> didn't say how to do it (examples are *SO* useful), and I can't imagine
> the solution.
In your case the solution is to type the six zeroes.
The comment referred to cases where the results of computations needed to
be forced to the right length, in which case you could use something like
substring(computation() || b'000000' for 6)
The question whether the constant should go before or after the
computation, and whether it should be zeros or ones is a matter of taste,
which is why an example has been omitted.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-07-07 10:59:36 | Re: Localization |
Previous Message | Carmen Wai | 2002-07-06 06:45:12 | Problem on PostgreSQL (error code, store procedures) |