Re: Javascript support in the backend, i.e. PL/JS
От | Sam Mason |
---|---|
Тема | Re: Javascript support in the backend, i.e. PL/JS |
Дата | |
Msg-id | 20071116161922.GW1955@frubble.xen.chris-lamb.co.uk обсуждение исходный текст |
Ответ на | Re: Javascript support in the backend, i.e. PL/JS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Javascript support in the backend, i.e. PL/JS
|
Список | pgsql-hackers |
On Fri, Nov 16, 2007 at 10:56:55AM -0500, Tom Lane wrote: > Sam Mason <sam@samason.me.uk> writes: > > For SPI, I'm thinking that I'd currently like to attempt some object > > orientated style interface. ... > > So running some SQL would probably look something like: > > > for (row in spi.prepare("SELECT 1 AS n").query()) { > > print(row.n); > > } > > What's not apparent to me is how one can avoid re-planning the query > every single time the function is called? Nothing. I've not got a good solution for avoiding replanning between invocations of the PL/JS function either. I wanted to get the most complicated case working first, and as of about 5 minutes ago, it appears to be. Code's still quite a mess, but seems to be functioning. > More generally, I think that the average programmer would rather just > not be bothered with all these details; he'd want to write > > for (row in spi.query("...sql..." [, arguments])) { ... > > I don't object to exposing the machinery for those who like to play with > such stuff, but you should have shortcuts to keep the simple things > simple. OK. Would you expect this to use cursors under the hood? I can't see a good way of making this work without them unless I accept that they're going to fail if the record set gets too large. Sam
В списке pgsql-hackers по дате отправления: