Thread: 7.3b2 ?bug? bitfromint4 is not working
Hi, I must be missing something obvious here but it seems that bitfromint4 is not working under 7.3b2. I can still see bitfromint4 in the source code, utils/adt/varbit.c, but it is no longer working. Any ideas why? Best wishes, Neophytos PS. It is also not working with the latest CVS checkout.
Neophytos Demetriou <k2pts@cytanet.com.cy> writes:
> I must be missing something obvious here but it seems that bitfromint4
> is not working under 7.3b2. I can still see bitfromint4 in the source
> code, utils/adt/varbit.c, but it is no longer working. Any ideas why?
It's still there:
regression=# select "bit"(42); bit
----------------------------------00000000000000000000000000101010
(1 row)
However, it's not listed in pg_cast :-(
regression=# select cast(42 as bit);
ERROR: Cannot cast type integer to bit
Looking at the CVS logs, this seems to be caused by overlapping changes.
On 4-Aug Thomas renamed bittoint4 and bitfromint4 to match the more
usual naming conventions for cast functions, viz int4(bit) and
bit(int4), and he also added int8(bit) and bit(int8). This was after
Peter had trolled the catalogs for cast functions and created the
initial contents of pg_cast.h (on 18-Jul).
Upshot: we have here four functions that ought to be in pg_cast and are
not.
Is it worth an initdb for 7.3b3 to fix this? I think we were already
considering forcing one for the command-tag issues, otherwise I'd
probably vote "no". Comments?
regards, tom lane
> Is it worth an initdb for 7.3b3 to fix this? I think we were already > considering forcing one for the command-tag issues, otherwise I'd > probably vote "no". Comments? Do we need an initdb to fix command tags? I thought that was just a change in the Query structure. --------------------------------------------------------------------------- Tom Lane wrote: > Neophytos Demetriou <k2pts@cytanet.com.cy> writes: > > I must be missing something obvious here but it seems that bitfromint4 > > is not working under 7.3b2. I can still see bitfromint4 in the source > > code, utils/adt/varbit.c, but it is no longer working. Any ideas why? > > It's still there: > > regression=# select "bit"(42); > bit > ---------------------------------- > 00000000000000000000000000101010 > (1 row) > > However, it's not listed in pg_cast :-( > > regression=# select cast(42 as bit); > ERROR: Cannot cast type integer to bit > > Looking at the CVS logs, this seems to be caused by overlapping changes. > On 4-Aug Thomas renamed bittoint4 and bitfromint4 to match the more > usual naming conventions for cast functions, viz int4(bit) and > bit(int4), and he also added int8(bit) and bit(int8). This was after > Peter had trolled the catalogs for cast functions and created the > initial contents of pg_cast.h (on 18-Jul). > > Upshot: we have here four functions that ought to be in pg_cast and are > not. > > Is it worth an initdb for 7.3b3 to fix this? I think we were already > considering forcing one for the command-tag issues, otherwise I'd > probably vote "no". Comments? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Do we need an initdb to fix command tags? I thought that was just a
> change in the Query structure.
A change in Query struct breaks stored rules. Looks like initdb
material to me ...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Do we need an initdb to fix command tags? I thought that was just a > > change in the Query structure. > > A change in Query struct breaks stored rules. Looks like initdb > material to me ... Oh, I forgot about stored rules. Yep, that would cause it. Not sure if fixing rule return is a valid initdb reason, but with the 'bit' type problem, seems it would be worth while. I am going to post in a few minutes about a push to get all those open items wrapped up. I think we are drifting. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073