Fwd: proposal GSoC 2015 task: Allow access to the database via HTTP

From: Вадим Горбачев <bmsdave(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Fwd: proposal GSoC 2015 task: Allow access to the database via HTTP
Date: 2015-03-23 17:12:28
Message-ID: CADmtSifNR6k+kTWuyyGJAzhUW+RqMp=1r9mKdwCzsYjJJeOuwQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> What is a benefit of this implementation for Postgres community?
It will be possible to clean this task from
https://wiki.postgresql.org/wiki/Todo

>> It can be interesting as well integrated project to Postgres -
implemented in C as background worker (if it possible)
I.e. as I understand http_api has to work in separate process at the server
of the DBMS.

And why not to start the free-standing application?
In this case there will be great opportunities for scaling:
1. through one http_api appendix it will be possible to be connected to
several DB
2. to use pgpool
3. to share burden between servers and so forth.
4. to carry out other functions of a frontend.

And what pluses writing of background worker will give?

If background worker is necessary, I am ready to realize it and it will be
interesting to me.
But whether it will be more necessary for postgresql, than the
free-standing application?

2015-03-23 19:24 GMT+03:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

> Hi
>
> 2015-03-22 23:28 GMT+01:00 Вадим Горбачев <bmsdave(at)gmail(dot)com>:
>
>> Hi Team.
>>
>> I would like to solve a problem of "Allow access to the database via
>> HTTP".
>>
>> But before drawing up the demand in GSOC I wanted to consult here.
>> Therefore I will be grateful to comments from attendees here!
>>
>> 1. I think, will better use access to DB through the stand-alone program
>> which not necessarily has to be on the same server. At least because it
>> will give certain freedom in cluster systems.
>>
>> 2. Whether it is obligatory to use a programming language C for this
>> purpose? After all as the stand-alone program ( frontend ) it has to be not
>> necessarily written in the same programming language as the server (
>> backend ). I would prefer to use the python language for writing as I
>> consider that this language is more clear to system administrators + to
>> bring much more simply editings in a code.
>>
>
> What is a benefit of this implementation for Postgres community?
>
> Proposed implementation is few lines in Python - and it is not big benefit
> for us. More, similar project exists.
>
> It can be interesting as well integrated project to Postgres - implemented
> in C as background worker (if it possible)
>
> Regards
>
> Pavel
>
>
>>
>> 3. What you will advise what to pass a selection stage in GSOC 2015 from
>> postgresql?)
>>
>> PS: my English is poor. I ask you to forgive me for it.
>>
>> Best Regards,
>> Vadim Gorbachov
>>
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-03-23 17:13:33 Re: logical column ordering
Previous Message Jeff Janes 2015-03-23 17:08:55 Re: logical column ordering