Re: HTTP Frontend? (and a brief thought on materialized views)
| От | Dobes Vandermeer |
|---|---|
| Тема | Re: HTTP Frontend? (and a brief thought on materialized views) |
| Дата | |
| Msg-id | CADbG_jawsDdzy=x-fZs+T_Dt_XFPyaRD9Wj1LH=EHDcdxSaCAg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: HTTP Frontend? (and a brief thought on materialized views) (Daniel Farina <daniel@heroku.com>) |
| Ответы |
Re: HTTP Frontend? (and a brief thought on materialized views)
|
| Список | pgsql-hackers |
On Sat, Mar 31, 2012 at 1:44 AM, Daniel Farina <daniel@heroku.com> wrote:
Just to be clear, what you are saying that writing a process that accepts requests by HTTP and translates them into requests using the existing protocol to send to the server would have unacceptable performance? Or is there something else about it that is a non-starter?On Fri, Mar 30, 2012 at 10:21 AM, Daniel Farina <daniel@heroku.com> wrote:I should add: proxying could work well if libpq had all the right
> 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 basically a non-starter outside
> the very earliest prototyping stages. The tuple scanning and protocol
> semantics can and even should remain the same, especially at first.
hooks. The server could remain ignorant. Regardless, upstream changes
result.
В списке pgsql-hackers по дате отправления: