Re: pgsql: Do execGrouping.c via expression eval machinery, take two.

Hi,

On 2018-02-16 22:48:39 +0000, Andres Freund wrote:
> Do execGrouping.c via expression eval machinery, take two.
>
> This has a performance benefit on own, although not hugely so. The
> primary benefit is that it will allow for to JIT tuple deforming and
> comparator invocations.
>
> Large parts of this were previously committed (773aec7aa), but the
> commit contained an omission around cross-type comparisons and was
> thus reverted.
>
> Author: Andres Freund
> Discussion: https://postgr.es/m/20171129080934.amqqkke2zjtekd4t@alap3.anarazel.de

This triggered a failure on rhinoceros, in the sepgsql test:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rhinoceros&dt=2018-02-16%2023%3A45%3A02

The relevant diff is:
+ LOG: SELinux: allowed { execute } scontext=unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0-s0:c0.c255 tcontext=system_u:object_r:sepgsql_proc_exec_t:s0 tclass=db_procedure name="pg_catalog.int4eq(integer,integer)"
and that's because we now invoke the function access hook for grouping
equal, which we previously didn't.

I personally think the new behaviour makes more sense, but if somebody
wants to argue differently? The only argument against I can see is that
there's some other cases where also don't yet invoke it, but that seems
weak.

I never fully grasped the exact use-case for the function execute hook
is, so maybe Kaigai and/or Robert could comment?

Greetings,

Andres Freund