Re: question about HTTP API - Mailing list pgsql-hackers

From Szymon Guz
Subject Re: question about HTTP API
Date
Msg-id CAFjNrYtwN1x5x-WfxrOgcssDpE4o_CcnVRN5bdp9Vwpv8xbV4A@mail.gmail.com
Whole thread Raw
In response to Re: question about HTTP API  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers



On 12 August 2013 18:37, Peter Eisentraut <peter_e@gmx.net> wrote:
On 8/8/13 3:44 PM, Josh Berkus wrote:
> Other than that, no.  I was thinking of creating a general tool as a
> custom background worker, which would take stored procedure calls and
> pass them through to PostgreSQL, returning results as JSON.  Mainly
> because I need it for a project.  However, this wouldn't accept any query.

You can write such a thing in 20 lines of code as an external service.
What's the value in having it has a background worker?  (Note also the
term *background* worker.)  It just seems harder to manage and scale
that way.


When I think about that, it seems to me like the only value of that would be a nice sql command for starting a service. On the other hand I could implement that in python/perl/C and start external server from the same sql query. When I started this thread I was thinking about writing some super simple app, in something like python/perl, and run it externally. I really don't like idea of having that in core, as it will be another thing to support, test etc. and another source of security/efficiency bugs. What we really need is something like phpPgAdmin with JSON/XML/Something api.

And one more thing: I would never let my db users to start such a service on their own.

Szymon

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: question about HTTP API
Next
From: Magnus Hagander
Date:
Subject: Re: pg_basebackup vs. Windows and tablespaces