Re: Proof of concept: standalone backend with full FE/BE protocol

On Thu, Nov 21, 2013 at 9:11 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Nov 21, 2013 at 2:14 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Peter Eisentraut <peter_e(at)gmx(dot)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 wants to 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