Re: [patch] pg_ctl init extension

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] pg_ctl init extension
Date: 2009-12-09 13:56:16
Message-ID: 3BB110AF-C3FE-4659-A8B9-60C02835BD7F@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Dec 9, 2009, at 8:32 AM, Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> wrote:

> Greg Smith píše v út 08. 12. 2009 v 22:44 -0500:
>> Zdenek Kotala wrote:
>>> thanks for your useful comments. I attached new doc patch
>>> version. I
>>> removed example changes and add link to create database cluster (I
>>> hope)
>>> everywhere. Please, look on it and let me know if there is still
>>> something what should be changed.
>>>
>> That looks much better. There's only one bit that sticks out oddly
>> now:
>>
>> + Note: The <command>initdb</command> might be invoked by
>> + <command>pg_ctl initdb</command> and <command>initdb</command>
>> cannot be in
>> + default path on a <productname>PostgreSQL</productname>
>> installations.
>>
>>
>>
>> What is that supposed to mean exactly?
>
> Ahh, It is somethink what I want to do, but it is not ready yet in
> this
> patch, but I already documented it. Idea is to install initdb and
> postgres into libexecdir and packager can select if libexecdir will be
> equal bindir or not.
>
> The paragraph should be removed at this moment. Shell I send modified
> patch or does committer remove it before commit?

I think Peter claimed this one but as far as I am concerned, I would
always rather have an updated patch.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ing. Marcos Ortiz Valmaseda 2009-12-09 13:56:52 Re: What happened to pl/proxy and FDW?
Previous Message Peter Eisentraut 2009-12-09 13:50:54 Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash