Re: Getting fancy errors when accessing information_schema on 10.5

> Am 30.10.2018 um 14:45 schrieb Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at <mailto:laurenz(dot)albe(at)cybertec(dot)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