On Thu, Feb 6, 2020 at 8:53 AM Amit Langote <amitlangot...@gmail.com> wrote: > > On Thu, Feb 6, 2020 at 4:31 PM Michael Paquier <mich...@paquier.xyz> wrote: > > On Thu, Feb 06, 2020 at 04:25:47PM +0900, Amit Langote wrote: > > > About the implementation, how about defining a static inline function, > > > say is_user_object(), next to FirstNormalObjectId's definition and > > > make pg_is_user_object() call it? There are a few placed in the > > > backend code that perform the same computation as pg_is_user_object(), > > > which could be changed to use is_user_object() instead. > > > > FWIW, if we bother adding SQL functions for that, my first impression > > was to have three functions, each one of them returning: > > - FirstNormalObjectId > > - FirstGenbkiObjectId > > - FirstNormalObjectId > > Did you miss FirstBootstrapObjectId by any chance? > > I see the following ranges as defined in transam.h. > > 1-(FirstGenbkiObjectId - 1): manually assigned OIDs > FirstGenbkiObjectId-(FirstBootstrapObjectId - 1): genbki.pl assigned OIDs > FirstBootstrapObjectId-(FirstNormalObjectId - 1): initdb requested > FirstNormalObjectId or greater: user-defined objects > > Sawada-san's proposal covers #4. Do we need an SQL function for the > first three? IOW, would the distinction between OIDs belonging to the > first three ranges be of interest to anyone except core PG hackers?
+1 for #4, but I'm not sure that the other 3 are really interesting to have at SQL level.
