| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Dave Cramer <pg(at)fastcrypt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-jdbc(at)postgresql(dot)org |
| Subject: | Re: [JDBC] Regarding GSoc Application |
| Date: | 2012-04-10 15:55:47 |
| Message-ID: | 4F845803.8090908@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-jdbc |
On 04/10/2012 11:36 AM, Tom Lane wrote:
> Atri Sharma<atri(dot)jiit(at)gmail(dot)com> writes:
>> On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Hm? SPI doesn't know anything about Java either.
>> We plan to call SQL through SPI from the FDW,which in turn would call
>> the Pl/Java routine.
> If you're saying that every Java function that the FDW needs would have
> to be exposed as a SQL function, that seems like a pretty high-risk
> (not to mention low performance) approach. Not only do you have to
> design a SQL representation for every datatype you need, but you have to
> be sure that you do not have any security holes arising from
> unscrupulous users calling those SQL functions manually with arguments
> of their choosing.
>
>
Yeah. I think this design is horribly baroque and unnecessary. SPI is
for talking SQL. It's completely in the way of a straight-forward
implementation of this feature IMNSHO.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-04-10 15:58:40 | Re: Patch: add timing of buffer I/O requests |
| Previous Message | Peter Geoghegan | 2012-04-10 15:55:20 | Re: To Do wiki |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2012-04-10 16:07:24 | Re: [JDBC] Regarding GSoc Application |
| Previous Message | Tom Lane | 2012-04-10 15:36:38 | Re: [JDBC] Regarding GSoc Application |