Re: Proof of concept: standalone backend with full FE/BE protocol
От | Amit Kapila |
---|---|
Тема | Re: Proof of concept: standalone backend with full FE/BE protocol |
Дата | |
Msg-id | CAA4eK1KoeaT0Su_dBTe6-bnhwrHoAfZXJdR50GsCgxH+g_Bk_w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proof of concept: standalone backend with full FE/BE protocol (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Proof of concept: standalone backend with full FE/BE protocol
|
Список | pgsql-hackers |
On Thu, Nov 21, 2013 at 9:11 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Thu, Nov 21, 2013 at 2:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Peter Eisentraut <peter_e@gmx.net> writes: >>> The argument elsewhere in this thread was that the reason for putting >>> this in the connection options was so that you do *not* have to patch up >>> every client to be able to use this functionality. If you have to add >>> separate options everywhere, then you might as well just have a separate >>> libpq function to initiate the session. >> >> Right, Andres was saying that we had to do both (special switches that >> lead to calling a special connection function). > > Doesn't the new option 'standalone_datadir' (which is already in > patch) a good candidate for special switch? > How does having one more new switch helps better? Here what I have in mind is that: a. In pg_dump or other internal utilities where we want to use this feature, they should call PQenableStart() or some other API before calling PQConnect() which will indicate that it wantsto operate as a standalone mode. b. In psql, if user specifies this special switch ( 'standalone_datadir'), then internally we will call PQenableStart() and use postgres from same directory. So standalone_backend option will not be exposed through psql, but other internal tools can use it. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: