Re: Accessing non catalog table in backend

On Mon, Jan 11, 2016 at 10:48 PM, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> wrote:

> Sorry, I missed this email.
>
> I was specifically targeting accessing tables inside Node evaluation hence
> do not want to add new nodes.
>
> Thanks for your inputs!
>
> Regards,
>
> Atri
>
> On Tue, Jan 5, 2016 at 11:43 AM, Amit Langote <
> Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
>> On 2016/01/05 14:30, Atri Sharma wrote:
>> > On Tue, Jan 5, 2016 at 9:54 AM, Amit Langote <
>> Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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.
>>
>>

Sorry for top posting.

Regards,

Atri