On Thu, 6 Feb 2020 at 16:53, 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?
Yeah I thought of these three values but I'm also not sure it's worth for users.
If we have these functions returning the values respectively, when we
want to check if an oid is assigned during initdb we will end up with
doing something like 'WHERE oid >= pg_first_bootstrap_oid() and oid <
pg_first_normal_oid()', which is not intuitive, I think. Users have to
remember the order of these values.
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
