| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
| Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Accessing non catalog table in backend |
| Date: | 2016-01-05 05:39:10 |
| Message-ID: | 24960.1451972350@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Atri Sharma <atri(dot)jiit(at)gmail(dot)com> writes:
> 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.
The code path executor -> PL function -> SPI certainly works, so
presumably omitting the intermediate PL function could still work.
Whether it's a good idea is another question entirely. I do not
offhand see a good reason why knowledge of non-system tables should
exist in the core executor; so what is the need to use SPI?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2016-01-05 05:50:40 | Re: dynloader.h missing in prebuilt package for Windows? |
| Previous Message | Chapman Flack | 2016-01-05 05:37:26 | Re: dynloader.h missing in prebuilt package for Windows? |