Thread: [PATCH] Cleanup: unify checks for catalog modification

[PATCH] Cleanup: unify checks for catalog modification

From
Marti Raudsepp
Date:
Hi list,

I happened to notice that there are no less than 14 places in the code
that check whether a relation is a system catalog and throwing the
error "permission denied: "foo" is a system catalog"

The attached patch factors all of those into a single
ForbidSystemTableMods() function. Is this considered an improvement?
Should I add it to CommitFest?

Regards,
Marti

Attachment

Re: [PATCH] Cleanup: unify checks for catalog modification

From
Tom Lane
Date:
Marti Raudsepp <marti@juffo.org> writes:
> I happened to notice that there are no less than 14 places in the code
> that check whether a relation is a system catalog and throwing the
> error "permission denied: "foo" is a system catalog"

> The attached patch factors all of those into a single
> ForbidSystemTableMods() function. Is this considered an improvement?

I'd argue not.  The code bulk savings is minimal, and this change
would degrade the usefulness of the file/line number reporting that's
built into ereport().  Admittedly it's a judgment call --- we've certainly
built error-reporting subroutines in cases where a significant amount of
complexity could be folded into the subroutine.  But I don't think this
case meets the threshold.
        regards, tom lane



Re: [PATCH] Cleanup: unify checks for catalog modification

From
Alvaro Herrera
Date:
Tom Lane wrote:
> Marti Raudsepp <marti@juffo.org> writes:
> > I happened to notice that there are no less than 14 places in the code
> > that check whether a relation is a system catalog and throwing the
> > error "permission denied: "foo" is a system catalog"
> 
> > The attached patch factors all of those into a single
> > ForbidSystemTableMods() function. Is this considered an improvement?
> 
> I'd argue not.  The code bulk savings is minimal, and this change
> would degrade the usefulness of the file/line number reporting that's
> built into ereport().

Along these lines, I've sometimes thought that it could be useful to
pass down file/line info from certain callers down to certain generic
check subroutines such as the one being proposed here.  (I can't recall
any specific examples offhand.)  Of course, doing it manually would be
very tedious and error prone, but perhaps we could have something like a
macro system that both sets up arguments in the called function, and
sets up the values in the callee.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services