Re: Identifying user-created objects

Поиск
Список
Период
Сортировка
От vignesh C
Тема Re: Identifying user-created objects
Дата
Msg-id CALDaNm1EwPLwzcuACqWr1kM6ukHu5=utJ4qawcozshrN88i1wQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Identifying user-created objects  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Ответы Re: Identifying user-created objects  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Some problems of recovery conflict wait events
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager