Re: BUG #15833: defining a comment on a domain constraint fails withwrong OID - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: BUG #15833: defining a comment on a domain constraint fails withwrong OID
Date
Msg-id 20190611133255.GA13589@alvherre.pgsql
Whole thread Raw
In response to Re: BUG #15833: defining a comment on a domain constraint fails withwrong OID  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #15833: defining a comment on a domain constraint fails withwrong OID
List pgsql-bugs
On 2019-Jun-11, Michael Paquier wrote:

> On Mon, Jun 10, 2019 at 08:55:27AM -0400, Alvaro Herrera wrote:
> > -1 on this approach.  Having this ownercheck function return the owning
> > object ID seems way too strange.  I'd rather not have the new ownercheck
> > function, and instead do a syscache search to obtain the type OID in
> > check_object_ownership, then do pg_type_ownercheck.  I'm not even sure
> > that pg_domain_constraint_ownercheck makes a lot of sense in itself,
> > since it's never the constraint that requires an owner check.
> 
> I can see your point, yes perhaps I overdid it.  What do you think
> about the attached instead?  This moves the syscache lookup directly
> into check_object_ownership() as you suggest.

Yeah, looks better.  I think the error message should be a normal elog()
cache failure, though ... at least in the COMMENT case, the obj-does-not-
exist message is supposed to be thrown by get_object_address(), before
check_object_ownership is called.

As a matter of style, I would get rid of the 'conoid' variable and just
use address.objectId where needed.


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



pgsql-bugs by date:

Previous
From: Fahar Abbas
Date:
Subject: Re: BUG #15834: Cannot install npgsql driver
Next
From: Tobias Gierke
Date:
Subject: (not a PG bug, please ignore) Re: PostgreSQL 11.3 hangs foreverduring DEALLOCATE statement