<OT> Argh, it is quite painful to keep all CC's in loop :(. I suppose
that something is broken with this list. Both of email replies missed my
MAILBOX and both have trimmed CC lists. Trying to reattach but not giving
it a big chance. </OT>
> ----- Original Message -----
> From: Florian Weimer <fweimer@redhat.com>
>
> On 06/23/2014 04:23 PM, Pavel Raiskup wrote:
> > What seems to be better approach is to have real configuration file,
> > such one for which '$ rpm -qc postgresql-server' would not be quiet.
> > Lets say:
> >
> > $ cat /etc/postgresql/postgresql
> > PGDATA=/some/other/place/than/default
>
> I think for Fedora, the file ought to be in /etc/sysconfig.
I'm not sure about this; right because /etc/sysconfig is Fedora specific
directory. We are discouraged to use that directory by systemd.. simply,
dunno. That said, both /etc/sysconfig/postgresql & /etc/postgresql would work
for me and I hope every admin is able to/aware of `rpm -qc postgresql-server`.
For the more cross-distro solution, I would prefer /etc/postgresql/
though.
> ----- Original Message -----
> From: Darin Perusich <darin@darins.net>
> On Mon, Jun 23, 2014 at 3:00 PM, Florian Weimer <fweimer@redhat.com> wrote:
> > On 06/23/2014 04:23 PM, Pavel Raiskup wrote:
> >> What seems to be better approach is to have real configuration file, such
> >> one
> >> for which '$ rpm -qc postgresql-server' would not be quiet. Lets say:
> >>
> >> $ cat /etc/postgresql/postgresql
> >> PGDATA=/some/other/place/than/default
> >
> > I think for Fedora, the file ought to be in /etc/sysconfig.
>
> The packages from yum.postgresql.org leverage
> /etc/sysconfig/pgsql/postgresql-VERSION. Theirs also leverages PGOPTS
> so one can set additional CLI options, say if you want to place your
> config files outside PGDATA with "-c
> config_file=/etc/postgresql/postgresql.conf".
I think that the part of README.rpm-dist from postgresql9{3,4} is outdated
as those parts describe SysV initscripts. Devrim?
Btw., that /etc/postgresql could calmly be shared by yum.postgresql.org
or any future SCL PostgreSQL as it should not collide by design - as long
as unit name do not clash, configuration should also not.
Pavel