| From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-11 17:19:09 |
| Message-ID: | CAOeZViekrGrXC8EFP4CJ6Z9=ck5rQkGzjnma3tzhXtNtfqL+Ag@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 5, 2016 at 11:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?
>
>
Thanks!
This was a weird requirement and managed to work around it but I will keep
this hack for future reference.
Regards,
Atri
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Atri Sharma | 2016-01-11 17:19:28 | Re: Accessing non catalog table in backend |
| Previous Message | Atri Sharma | 2016-01-11 17:18:22 | Re: Accessing non catalog table in backend |