Re: Identifying user-created objects - Mailing list pgsql-hackers

From vignesh C
Subject Re: Identifying user-created objects
Date
Msg-id CALDaNm1EwPLwzcuACqWr1kM6ukHu5=utJ4qawcozshrN88i1wQ@mail.gmail.com
Whole thread Raw
In response to Re: Identifying user-created objects  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses Re: Identifying user-created objects  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
List pgsql-hackers
On Wed, Mar 4, 2020 at 9:02 AM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> On Tue, 3 Mar 2020 at 23:33, vignesh C <vignesh21@gmail.com> wrote:
> >
> > Should we add some check if object exists or not here:
> > +Datum
> > +pg_is_user_object(PG_FUNCTION_ARGS)
> > +{
> > +    Oid oid = PG_GETARG_OID(0);
> > +
> > +    PG_RETURN_BOOL(ObjectIsUserObject(oid));
> > +}
> >
> > I was trying some scenarios where we pass an object which does not exist:
> > postgres=# SELECT pg_is_user_object(0);
> >  pg_is_user_object
> > -------------------
> >  f
> > (1 row)
> > postgres=# SELECT pg_is_user_object(222222);
> >  pg_is_user_object
> > -------------------
> >  t
> > (1 row)
> > SELECT pg_is_user_object('pg_class1'::regclass);
> > ERROR:  relation "pg_class1" does not exist
> > LINE 1: SELECT pg_is_user_object('pg_class1'::regclass);
> >                                  ^
> > I felt these behavior seems to be slightly inconsistent.
> > Thoughts?
> >
>
> Hmm I'm not sure we should existing check in that function. Main use
> case would be passing an oid of a tuple of a system catalog to that
> function to check if the given object was created while multi-user
> mode. So I think this function can assume that the given object id
> exists. And if we want to do that check, we will end up with checking
> if the object having that oid in all system catalogs, which is very
> high cost I think.
>
> I suspect perhaps the function name pg_is_user_object led that
> confusion. That name looks like it checks if the given 'object' is
> created while multi-user mode. So maybe we can improve it either by
> renaming to pg_is_user_object_id (or pg_is_user_oid?) or leaving the
> name but describing in the doc (based on Amit's suggestion in previous
> mail):

I liked pg_is_user_oid over pg_is_user_object_id but this liking may
vary from person to person, so I'm still ok if you don't change the
name. I'm fine about adding the information in the document unless
someone else feels that this check is required in this function.

Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Some problems of recovery conflict wait events
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager