Re: Javascript support in the backend, i.e. PL/JS

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Javascript support in the backend, i.e. PL/JS
Date: 2007-11-16 16:19:22
Message-ID: 20071116161922.GW1955@frubble.xen.chris-lamb.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 16, 2007 at 10:56:55AM -0500, Tom Lane wrote:
> Sam Mason <sam(at)samason(dot)me(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-11-16 16:22:23 Re: strange tuple from ExecutorRun
Previous Message Magnus Hagander 2007-11-16 16:18:33 Re: [COMMITTERS] pgsql: update files for beta3