On Fri, Nov 8, 2024 at 8:36 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Dilip Kumar <dilipbal...@gmail.com> writes:
> > IIRC, In catalog we intentionally left it as Oid because RelFileNumber is
> > an internal typedef bug, it is not an exposed datatype, so probably we
> can
> > not use it in catalog.
>
> We could declare it as RelFileNumber so that that is what C code sees,
> and teach Catalog.pm to translate that to OID in the emitted catalog
> contents.
Yeah that make sense and yes we can actually keep this change
> I think you'd have to do that to avoid a ton of false
> positives when you make RelFileNumber into a struct, and we might as
> well keep the result.
>
Even after this, there were tons of false positives, whenever using any
comparison operator on relfilenumbers[1] and there are tons of those, or
using them in log messages with %u [2]. Anyway, I have gone through those
manually and after ignoring all false positives here is what I got, PFA
patch (odd 25 places where I have fixed usage of Oid instead of
RelFileNumbers).
[1]
../../../../src/include/storage/buf_internals.h:157:20: error: invalid
operands to binary expression ('const RelFileNumber' (aka 'const struct
RelFileNumber') and 'const RelFileNumber')
(tag1->relNumber == tag2->relNumber)
[2]
fsmpage.c:277:47: warning: format specifies type 'unsigned int' but the
argument has type 'RelFileNumber' (aka 'struct RelFileNumber') [-Wformat]
blknum, rlocator.spcOid, rlocator.dbOid,
rlocator.relNumber);
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
remove_using_oid_for_relfilenumber.patch
Description: Binary data
