On Wed, Feb 2, 2022 at 6:57 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, Jan 31, 2022 at 9:37 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > I agree that we are using 8 bytes unsigned int multiple places in code > > as uint64. But I don't see it as an exposed data type and not used as > > part of any exposed function. But we will have to use the relfilenode > > in the exposed c function e.g. > > binary_upgrade_set_next_heap_relfilenode(). > > Oh, I thought we were talking about the C data type uint8 i.e. an > 8-bit unsigned integer. Which in retrospect was a dumb thought because > you said you wanted to store the relfilenode AND the fork number > there, which only make sense if you were talking about SQL data types > rather than C data types. It is confusing that we have an SQL data > type called int8 and a C data type called int8 and they're not the > same. > > But if you're talking about SQL data types, why? pg_class only stores > the relfilenode and not the fork number currently, and I don't see why > that would change. I think that the data type for the relfilenode > column would change to a 64-bit signed integer (i.e. bigint or int8) > that only ever uses the low-order 56 bits, and then when you need to > store a relfilenode and a fork number in the same 8-byte quantity > you'd do that using either a struct with bit fields or by something > like combined = ((uint64) signed_representation_of_relfilenode) | > (((int) forknumber) << 56);
Yeah you're right. I think whenever we are using combined then we can use uint64 C type and in pg_class we can keep it as int64 because that is only representing the relfilenode part. I think I was just confused and tried to use the same data type everywhere whether it is combined with fork number or not. Thanks for your input, I will change this. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com