Re: Accessing non catalog table in backend - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Accessing non catalog table in backend
Date
Msg-id 568B5F03.5070408@lab.ntt.co.jp
Whole thread Raw
In response to Re: Accessing non catalog table in backend  (Atri Sharma <atri.jiit@gmail.com>)
Responses Re: Accessing non catalog table in backend  (Atri Sharma <atri.jiit@gmail.com>)
List pgsql-hackers
On 2016/01/05 14:30, Atri Sharma wrote:
> On Tue, Jan 5, 2016 at 9:54 AM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
>> On 2016/01/05 3:53, Atri Sharma wrote:
>>> I was wary to use SPI inside the executor for node evaluation functions.
>>> Does it seem safe?
>>
>> What is "node evaluation functions"? Is it "Plan" nodes or "Expr" nodes
>> that you are talking about? I guess you'd know to use ExecProcNode() or
>> ExecEvalExpr() for them, respectively.
>>
> I fail to see the relevance of which node is getting evaluated (its a Plan
> node BTW) for this question. The concern I had was around using SPI inside
> executor and its fail safety.

Sorry, I may have misunderstood your question(s). Seeing your first
question in the thread, I see that you're looking to query non-system
tables within the executor. AFAIU, most of the processing within executor
takes the form of some node in some execution pipeline of a plan tree.
Perhaps, you're imagining some kind of node, subnode or some such. By the
way, some places like ATRewriteTable(), validateCheckConstraint() scan
user tables directly using low-level utilities within a dummy executor
context. I think Jim suggested something like that upthread.

Thanks,
Amit





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Keyword classifications
Next
From: Simon Riggs
Date:
Subject: Re: ALTER TABLE behind-the-scenes effects' CONTEXT