Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hagth-00038X-2A for pgsql-bugs@arkaria.postgresql.org; Tue, 11 Jun 2019 13:33:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hagtf-0001ae-Gm for pgsql-bugs@arkaria.postgresql.org; Tue, 11 Jun 2019 13:33:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hagtf-0001Wz-1s for pgsql-bugs@lists.postgresql.org; Tue, 11 Jun 2019 13:33:07 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hagtb-0005j0-NP for pgsql-bugs@lists.postgresql.org; Tue, 11 Jun 2019 13:33:06 +0000 Received: by mail-qt1-x844.google.com with SMTP id n11so12359765qtl.5 for ; Tue, 11 Jun 2019 06:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=bF3ViagVVDoy0vh4/w2W3cxv2EF7Uv3vbILyZWAEOsg=; b=dqOLpASFNJMU/RA/aXD5wYBXymhrKHRTztSNV3OpUCSKgnwBwXQi+tgvpEyG8jiBGm ezvskZgtm9pcCRqWgCNij7Li6K8x2+X+5b0IKYYtwSqcZ+OZwo/KwL9RuUf6fR5BZpdU Qfp/TpSDUIA9RIhkcxm5e9+d1CXoS9DaMEo6cXyT8n/nueCUNQAi28/VowutoizSHs0/ BCMWd4qtBlPQ9lm3IOPKDU0kW0sWL4KHCm9o7fbKKk5EUodjGbHKsVZddkUQWlllmEwD eLCj7bsi0CL5geSZJnAnQwdcoAU37RcFbXkQwizRHTGvazLCKysv+MZ8D5yc+VXsbIVb gicA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=bF3ViagVVDoy0vh4/w2W3cxv2EF7Uv3vbILyZWAEOsg=; b=pVe2hCWobqCsayeO+jt+OROl/msOdFZvrEcz707cCx6d3LN9Q9qj98tGMtmXeD2WmR F5fyP6ecD0PdWyD3Tm/Ur+hrBMwKuVy79pA7RFRTLL398Zx5/lo5AnRggFz12DY6IaBJ nKLAe+nQLACZM3+D0Gh/fzTNTcag1bzm2Pt8tbc6/RDq/quPLS4ePUUu1pPmUAMK2DDg vioxRHfgiVn4rBBwowdqipHcA10/wjcGtEy9OEtBqppH97+VZ+JdAyNvUciou/y6eLO1 d1qmao8JsRBjhAiKjgXijhWurQqo4+7Tnl2ZIztZLB28wZf+TfMd/0KH5SqteNUbRuNW ARNA== X-Gm-Message-State: APjAAAWKp31/PthQ6ld9Am28wcFdT2Dt6tjktr1DSkVpfXkiuvRlQfi4 VRv1ZFVYEv7GwjZfcEoqS7ChuA== X-Google-Smtp-Source: APXvYqwTmgh4qawd+S9ofpreZwVs3H1hEZ8qc3tPMoSxr3gua57uiMR2zNXEYQAtSxT0pdyHuiHsJg== X-Received: by 2002:a05:6214:1cc:: with SMTP id c12mr48430705qvt.119.1560259981414; Tue, 11 Jun 2019 06:33:01 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([177.154.139.203]) by smtp.gmail.com with ESMTPSA id r39sm7857614qtc.87.2019.06.11.06.32.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Jun 2019 06:33:00 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 28290120859; Tue, 11 Jun 2019 09:32:55 -0400 (-04) Date: Tue, 11 Jun 2019 09:32:55 -0400 From: Alvaro Herrera To: Michael Paquier Cc: Daniel Gustafsson , clemens@ladisch.de, PostgreSQL mailing lists Subject: Re: BUG #15833: defining a comment on a domain constraint fails with wrong OID Message-ID: <20190611133255.GA13589@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190611045539.GB2132@paquier.xyz> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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