Re: Javascript support in the backend, i.e. PL/JS - Mailing list pgsql-hackers

From Sam Mason
Subject Re: Javascript support in the backend, i.e. PL/JS
Date
Msg-id 20071116161922.GW1955@frubble.xen.chris-lamb.co.uk
Whole thread Raw
In response to Re: Javascript support in the backend, i.e. PL/JS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Javascript support in the backend, i.e. PL/JS  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [COMMITTERS] pgsql: update files for beta3
Next
From: Tom Lane
Date:
Subject: Re: strange tuple from ExecutorRun