Message-ID: <4F75DB1D.5080403@dunslane.net>
Date: Fri, 30 Mar 2012 12:11:09 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>
CC: Dobes Vandermeer <dobesv@gmail.com>, Daniel Farina <daniel@heroku.com>,
	pgsql-hackers@postgresql.org
Subject: Re: HTTP Frontend? (and a brief thought on materialized
 views)
References: 
 <CADbG_jax4vwvfRQ9u2X4xAdWfiB7nqpopDxxQTQ10xJKMmzTRQ@mail.gmail.com>
	<4F7479FE.9050702@dunslane.net>
	<CAAZKuFaW3jvH=9fAtAOr+V3=pYNvTmM5dCrc-Ba=GQ+CpULX=g@mail.gmail.com>
	<CAAZKuFbXTc=P7kfknro853agQNraCnmX7HD6ULx8piC4JcP6rg@mail.gmail.com>
	<CADbG_jYnVCK6Zj3iC5kmSk7HA2jpTJK1U0kpxWoiK1gymRBQ-g@mail.gmail.com>
	<CAAZKuFbNO8_nmS9LGnznaRJrjNvKRRa4-rJme38pv-roJyGnHQ@mail.gmail.com>
	<CADbG_jY_HOfn4LJ-hGxqrc7ww6DxHC93Ndqhp3CKCs27-P2R0Q@mail.gmail.com>
	<CAAZKuFaY_xW5+9R+Mr5q2MH9bPYBwwf0=D6a_hv8uCjXpb73xA@mail.gmail.com>
	<CADbG_jbGz8S=PN80DUQMX0L-jTXyJWRYUQ9z53_hBrLkwKmMbg@mail.gmail.com>
	<CA+TgmoZ7GiMgGSb0PfDyN3fosh2u0_8xD8X7JwQO624Nr7RAag@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoZ7GiMgGSb0PfDyN3fosh2u0_8xD8X7JwQO624Nr7RAag@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 03/30/2012 11:41 AM, Robert Haas wrote:
> On Fri, Mar 30, 2012 at 10:55 AM, Dobes Vandermeer<dobesv@gmail.com>  wrote:
>> Well, in our case HTTP is a clear win (but not replacement) and SPDY a
>> potential one (even as a replacement).  Even if SPDY is not widely adopted
>> it could still replace FEBE if there's a clear advantage to using it, I
>> don't know enough to make the call right now.
> I can see that there are some advantages to having an HTTP interface
> to the database, but I think throwing our existing protocol out the
> window or relegating it to the status of a second-class citizen would
> be foolish.


Right, I can't imagine it happening. And I wouldn't really be keen to 
add an alternative protocol either.

I could imagine a client which presented a SPDY interface to the world 
and translated it into standard calls, possibly via libpq.

It's well to remember that we are not a green fields project here.


> HTTP is a non-trivial protocol that tends to impose lots
> of escaping and de-escaping overhead which is unnecessary for people
> who just want to connect to the database and run queries.  I can
> completely understand that someone might want the ability to do GET
> /db/table/pk and have that return an answer very, very quickly, by
> bypassing the usual parser and planner and just firing off an
> index-scan and returning the results as JSON or somesuch.  But I think
> it would be a serious mistake to assume that GET /q?q=myquery is going
> to come out better than what we have now in the general case.


Indeed.

cheers

andrew