From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marti Raudsepp <marti(at)juffo(dot)org> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: [PATCH] Caching for stable expressions with constant arguments v3 |
Date: | 2011-12-07 22:24:32 |
Message-ID: | 22021.1323296672@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marti Raudsepp <marti(at)juffo(dot)org> writes:
> Let me rephrase that as a question: Does it seem worthwhile to add a
> new argument to ExecInitExpr to handle those two cases?
Possibly. Another way would be to keep its API as-is and introduce a
different function name for the other behavior. I would think that
we'd always know for any given caller which behavior we need, so a
flag as such isn't notationally helpful.
> Does relying
> on the PlanState argument being NULL seem like a bad idea for any
> reason?
Yes, that seemed like a pretty horrid idea when I read your description,
but I hadn't got round to looking at just how awful it might be.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-12-08 00:51:05 | Re: documentation issue - extensions |
Previous Message | Marti Raudsepp | 2011-12-07 21:58:23 | Re: [PATCH] Caching for stable expressions with constant arguments v3 |