Hi guys,
Something from Josh's recent blog post about summer of code clicked with me
- the HTTP / SQL concept.
It was something I'd been thinking about earlier, how people really like
HTTP APIs and this is one of the drivers behind adoption of some "NoSQL"
databases out there.
Some things that
On Thu, Mar 29, 2012 at 11:04 PM, Andrew Dunstan wrote:
>
> On 03/29/2012 10:37 AM, Dobes Vandermeer wrote:
>
>> Hi guys,
>>
>> Something from Josh's recent blog post about summer of code clicked with
>> me - the HTTP / SQL concept.
>>
>>
&g
On Fri, Mar 30, 2012 at 3:59 AM, Daniel Farina wrote:
> On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina
> wrote:
More technical concerns:
> > * Protocol compression -- but a bit of sand in the gears is *which*
> > compression -- for database workloads, the performance of zlib can be
> > a meani
On Fri, Mar 30, 2012 at 3:57 AM, Daniel Farina wrote:
> On Thu, Mar 29, 2012 at 8:04 AM, Andrew Dunstan
> wrote:
>
> Lastly, a case that can not as easily be fixed without some more
> thinking is leveraging caching semantics of HTTP. think people would
> really, really like that, if they cou
On Fri, Mar 30, 2012 at 10:55 AM, Daniel Farina wrote:
> On Thu, Mar 29, 2012 at 6:37 PM, Dobes Vandermeer
> wrote:
> > On Fri, Mar 30, 2012 at 3:59 AM, Daniel Farina
> wrote:
> >>
> >> On Thu, Mar 29, 2012 at 12:57 PM, Daniel Farina
> >>
On Fri, Mar 30, 2012 at 4:30 PM, Daniel Farina wrote:
> On Thu, Mar 29, 2012 at 10:55 PM, Dobes Vandermeer
> wrote:
> >> Virtual hosts. Same port.>> I think SPDY or like-protocols [...] give a
> crisp treatment to
> >> interactive, stateful workloads involving
On Fri, Mar 30, 2012 at 9:57 PM, Merlin Moncure wrote:
> On Thu, Mar 29, 2012 at 10:04 AM, Andrew Dunstan
> wrote:
> > 1. I've been in discussion with some people about adding simple JSON
> extract
> > functions. We already have some (i.e. xpath()) for XML.
>
> Your json work is a great start in
I had a thought that it might be interesting to have a simple C fronted
that converts HTTP to and from some pgsql friendly structure and delegates
all the core logic to a stored procedure in the database.
This might make it easier to hack on the API without worrying about memory
management and buf
On Sat, Mar 31, 2012 at 1:44 AM, Daniel Farina wrote:
> On Fri, Mar 30, 2012 at 10:21 AM, Daniel Farina wrote:
> > Any enhancement here that can't be used with libpq via, say, drop-in
> > .so seems unworkable to me, and that's why any solution that is
> > basically proxying to the database is ba
On Wed, Apr 4, 2012 at 6:26 AM, Josh Berkus wrote:
>
> > While I was doing this I always thought this would have been a better
> > approach for my previous project, an accounting application. If I could
> > just have stored entities like invoice & customer as a single document
> that
> > is inse
A while back I was working on a little proposal to create a RESTful HTTP
front-end for PostgreSQL and recently I had the inspiration to work on
this. So I successfully created a background worker for PostgreSQL 9.3
that can use the SPI to list off the databases in a JSON response.
WIP on github:
ay, there seem to be some
other options out there already.
Thanks for the feedback.
On Aug 31, 2014 8:46 PM, "Craig Ringer" wrote:
> On 08/31/2014 12:40 PM, Dobes Vandermeer wrote:
> > 1. Connecting to multiple databases
> >
> > The background workers can apparen
On Mon, Sep 1, 2014 at 7:00 PM, Craig Ringer wrote:
> On 09/02/2014 12:50 AM, Dobes Vandermeer wrote:
> > Hmm yes I am learning that the BG worker system isn't as helpful as I
> > had hoped due to the single database restriction.
> >
> > As for a writing a
13 matches
Mail list logo
