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
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 |