Re: Getting fancy errors when accessing information_schema on 10.5

> Am 30.10.2018 um 14:45 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
> 
> Laurenz Albe <laurenz.albe@cybertec.at <mailto:laurenz.albe@cybertec.at>> 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_privilege(oid, 'SELECT, UPDATE, USAGE'::text))) from pg_class;
> 
> explain select (relkind = ’S'::"char") from pg_class;

nextcloud=> explain select ((pg_has_role(relowner, 'USAGE'::text) OR has_sequence_privilege(oid, 'SELECT, UPDATE, USAGE'::text))) from pg_class;
                        QUERY PLAN                         
-----------------------------------------------------------
 Seq Scan on pg_class  (cost=0.00..28.56 rows=656 width=1)
(1 row)

nextcloud=> explain select (relkind = 'S'::"char") from pg_class;
                        QUERY PLAN                         
-----------------------------------------------------------
 Seq Scan on pg_class  (cost=0.00..28.56 rows=656 width=1)
(1 row)

> 
> 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.


Axel
---
PGP-Key:29E99DD6  ☀  computing @ chaos claudius