Re: Add support for AT LOCAL

On Tue, Oct 03, 2023 at 02:10:48AM +0200, Vik Fearing wrote:
> On 9/29/23 09:27, Michael Paquier wrote:
>> As the deparsing code introduced by this patch is showing, this leads
>> to a lot of extra complexity. And, actually, this can be quite
>> expensive as well with these two layers of functions. Note also that
>> in comparison to SQLValueFunctions, COERCE_SQL_SYNTAX does less
>> inlining. So here comes my question: why doesn't this stuff just use
>> one underlying function to do this job?
>
> I guess I don't understand the question. Why do you think a single function
> that repeats what these functions do would be preferable? I am not sure how
> doing it a different way would be better.

Leaving aside the ruleutils.c changes introduced by the patch that are
quite confusing, having one function in the executor stack is going to
be more efficient than two (aka less ExecInitFunc), and this syntax
could be used in SQL queries where the operations is repeated a lot.
This patch introduces two COERCE_SQL_SYNTAX, meaning that we would do
twice the ACL check, twice the function hook, etc, so this could lead
to significant differences. I think that we should be careful with
the approach taken, and do benchmarks to choose an efficient approach
from the start. See for example:
https://www.postgresql.org/message-id/ZGHBGE45jKW8FEpe@paquier.xyz
--
Michael