Re: Identifying user-created objects

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(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 06:28:13
Message-ID: CALDaNm1EwPLwzcuACqWr1kM6ukHu5=utJ4qawcozshrN88i1wQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-03-04 06:32:54 Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Previous Message Fujii Masao 2020-03-04 06:21:00 Re: Some problems of recovery conflict wait events