From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | ExecPrepareExprList and per-query context |
Date: | 2017-04-07 10:05:53 |
Message-ID: | aad31672-4983-d95d-d24e-6b42fee9b985@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
As of b8d7f053c5c, ExecPrepareExprList is (must be?) used instead of
ExecPrepareExpr when the caller wants to initialize expressions in a list,
for example, FormIndexDatum. ExecPrepareExpr doesn't require the caller
to have switched to per-query context, because it itself will. Same is
not however true for the new ExecPrepareExprList. That means the List
node that it creates might be in a context that is not necessarily
per-query context, where it previously would be. That breaks third-party
users of FormIndexDatum that rely on the list to have been created in
per-query context (pg_bulkload was broken by this).
Should ExecPrepareExprList also switch to estate->es_query_cxt? Or maybe
ExecPrepareExpr could itself detect that passed-in node is a List and
create the list of ExprState nodes by itself. I guess the reason to
separate list case is because ExecInitExpr() does not take Lists anymore.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Prakash Itnal | 2017-04-07 10:16:33 | Performance issue with postgres9.6 |
Previous Message | Etsuro Fujita | 2017-04-07 10:05:31 | Re: Declarative partitioning - another take |