Horton

Re: [PATCH] Caching for stable expressions with constant arguments v3

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Marti Raudsepp <marti@juffo.org>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Josh Berkus <josh@agliodbs.com>
Date: 2011-12-07T22:24:32Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. include_if_exists facility for config file.

Marti Raudsepp <marti@juffo.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