| 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: | Whole Thread | Raw Message | 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 |