Re: Identifying user-created objects

From: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Identifying user-created objects
Date: 2020-03-04 11:06:48
Message-ID: CA+fd4k4BaZ0N0AT8m7bDAcHUc5q2BBW24ovbT_zdN_KvPrCFNA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 4 Mar 2020 at 15:28, vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Wed, Mar 4, 2020 at 9:02 AM Masahiko Sawada
> <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
> >
> > On Tue, 3 Mar 2020 at 23:33, vignesh C <vignesh21(at)gmail(dot)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.
>

Attached updated patch that incorporated comments from Amit and Vignesh.

Regards,

--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
identify_user_object_v4.patch application/x-patch 5.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mahendra Singh Thalor 2020-03-04 11:16:29 Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Previous Message Fujii Masao 2020-03-04 10:36:03 Re: Re: [HACKERS] make async slave to wait for lsn to be replayed