Re: Allowing REINDEX to have an optional name

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Bernd Helmle <mailings(at)oopsware(dot)de>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Subject: Re: Allowing REINDEX to have an optional name
Date: 2022-07-04 08:26:19
Message-ID: 20220704082619.exueqneu6ehpqk54@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2022-Jun-29, Simon Riggs wrote:

> > - if (strcmp(objectName, get_database_name(objectOid)) != 0)
> > + if (objectName && strcmp(objectName, get_database_name(objectOid)) != 0)
> > ereport(ERROR,
> > (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> > errmsg("can only reindex the currently open database")));
> > if (!pg_database_ownercheck(objectOid, GetUserId()))
> > aclcheck_error(ACLCHECK_NOT_OWNER, OBJECT_DATABASE,
> > - objectName);
> > + get_database_name(objectOid));
> >
> > This could call get_database_name() just once.
>
> It could, but I couldn't see any benefit in changing that for the code
> under discussion.
>
> If calling get_database_name() multiple times is an issue, I've added
> a cache for that - another patch attached, if you think its worth it.

TBH I doubt that this is an issue: since we're throwing an error anyway,
the memory would be released, and error cases are not considered worth
of performance optimization anyway.

Putting that thought aside, if we were to think that this is an issue, I
don't think the cache as implemented here is a good idea, because then
caller is responsible for tracking whether to free or not the return
value.

I think that Michaël's idea could be implemented more easily by having a
local variable that receives the return value from get_database_name.
But I think the coding as Simon had it was all right.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Las navajas y los monos deben estar siempre distantes" (Germán Poo)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-07-04 08:27:44 Re: Using PQexecQuery in pipeline mode produces unexpected Close messages
Previous Message shiy.fnst@fujitsu.com 2022-07-04 08:16:45 RE: Handle infinite recursion in logical replication setup