Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHUL8-000382-KS for pgsql-admin@arkaria.postgresql.org; Tue, 30 Oct 2018 13:45:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gHUL6-00062N-Mm for pgsql-admin@arkaria.postgresql.org; Tue, 30 Oct 2018 13:45:48 +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_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHUL6-00062G-Ef for pgsql-admin@lists.postgresql.org; Tue, 30 Oct 2018 13:45:48 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHUL4-0007ZB-DT for pgsql-admin@postgresql.org; Tue, 30 Oct 2018 13:45:48 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w9UDjYNt015909; Tue, 30 Oct 2018 09:45:34 -0400 From: Tom Lane To: Laurenz Albe cc: Axel Rau , pgsql-admin@postgresql.org Subject: Re: Getting fancy errors when accessing information_schema on 10.5 In-reply-to: <31055688b81895792fa7d8c61e07dca7add3dbb9.camel@cybertec.at> References: <4880e067723cefc1dc2e08a117f96de26ae0f797.camel@cybertec.at> <44D4C7B1-0DCF-4166-9DB8-B5D75EB2985E@Chaos1.DE> <20191.1540901834@sss.pgh.pa.us> <31055688b81895792fa7d8c61e07dca7add3dbb9.camel@cybertec.at> Comments: In-reply-to Laurenz Albe message dated "Tue, 30 Oct 2018 14:18:12 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15907.1540907134.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2018 09:45:34 -0400 Message-ID: <15908.1540907134@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Laurenz Albe writes: > Tom Lane wrote: >> It doesn't happen for me either. Looking at the planner code, it seems >> like the relkind check should happen first because it'd be cheaper than >> the OR condition. > It is still unclear why the execution plan looks like that, but maybe > it would be more robust to change "has_sequence_privilege" so that it > just returns FALSE if the argument is not a sequence. I was wondering about that, but somewhere along there we'd be losing all semblance of error checking on the OID argument, so it's not all that attractive a solution. I'd prefer to understand why this isn't behaving the same as it does for other people before we resort to that. Axel, would you try two more things on that DB? explain select ((pg_has_role(relowner, 'USAGE'::text) OR has_sequence_priv= ilege(oid, 'SELECT, UPDATE, USAGE'::text))) from pg_class; explain select (relkind =3D 'S'::"char") from pg_class; That's just to positively confirm that the planner thinks the former expression is more expensive than the latter. Assuming that it does, the only other answer I can think of is that there's something wrong with the insertion sort code in order_qual_clauses. Pretty hard to see what, though. regards, tom lane