On Thu, Feb 6, 2020 at 8:53 AM Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Feb 6, 2020 at 4:31 PM Michael Paquier <michael@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.