On Wed, Sep 21, 2022 at 6:09 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > Yeah you are right we can make it uint64. With respect to this, we > can not directly use uint64 because that is declared in c.h and that > can not be used in > postgres_ext.h IIUC.
Ugh. > Can we move the existing definitions from > c.h file to some common file (common for client and server)? Yeah, I think that would be a good idea. Here's a quick patch that moves them to common/relpath.h, which seems like a possibly-reasonable choice, though perhaps you or someone else will have a better idea. > Based on the discussion [1], it seems we can not use > INT64_FORMAT/UINT64_FORMAT while using ereport. But all other places > I am using INT64_FORMAT/UINT64_FORMAT. Does this make sense? > > [1] > https://www.postgresql.org/message-id/20220730113922.qd7qmenwcmzyacje%40alvherre.pgsql Oh, hmm. So you're saying if the string is not translated then use (U)INT64_FORMAT but if it is translated then cast? I guess that makes sense. It feels a bit strange to have the style dependent on the context like that, but maybe it's fine. I'll reread with that idea in mind. > If we're going to bank on that, we could adapt this more > > heavily, e.g. RelidByRelfilenumber() could lose the reltablespace > > parameter. > > Yeah we might, although we need a bool to identify whether it is > shared relation or not. Why? -- Robert Haas EDB: http://www.enterprisedb.com
move-relfilenumber-decls-v1.patch
Description: Binary data