thanks for information! I understood your idea. I originally assumed such structure: https://drive.google.com/file/d/0B4zY7CurvRqwWE9EZUpBU1FpSTQ/view?usp=sharing https://drive.google.com/file/d/0B4zY7CurvRqwSWpCRjlNVWdlMWc/view?usp=sharing https://drive.google.com/file/d/0B4zY7CurvRqwa0RYQ2tldWY5dWM/view?usp=sharing https://drive.google.com/file/d/0B4zY7CurvRqwLXZ6UzV4Q3lfclk/view?usp=sharing
But your option will be more convenient: https://drive.google.com/file/d/0B4zY7CurvRqwZUJRdlBadEFIelE/view?usp=sharing I will think over it... If someone else shares councils, I will be very grateful! Best Regards, Vadim Gorbachov 2015-03-23 20:26 GMT+03:00 Pavel Stehule <pavel.steh...@gmail.com>: > > > 2015-03-23 18:10 GMT+01:00 Вадим Горбачев <bmsd...@gmail.com>: > >> >> 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? >> > > integration to Postgres - simply (usual) deployment. Fast access to > PostgreSQL shared memory, fast access to database. > > Now anybody can using pgpool, pgbouncer, light httpd, simple fast CGI > script without problems. > > > >> 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.steh...@gmail.com>: >> >>> Hi >>> >>> 2015-03-22 23:28 GMT+01:00 Вадим Горбачев <bmsd...@gmail.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 >>>> >>> >>> >> >
