On Thursday 13 February 2003 21:13, Bruce Momjian wrote:
> Lamar Owen wrote:
> > It isn't without precedent to have a directory under /var/run. Maybe
> > /var/run/postgresql. Under this one could have a uniquely named pid
> > file.
> But how do you handle the default then, where you have postmas
On Thu, 13 Feb 2003, scott.marlowe wrote:
> If I do a .tar.gz install of apache, I get /usr/local/apache/conf, which
> is not the standard way you're listing.
I'm going to stay out of this argument from now on, but this struck a sore
point.
/usr is designed to be a filesystem that can be shared.
> On 13 Feb 2003, Oliver Elphick wrote:
>
> > What your comments strongly suggest to me is that projects like
> > PostgreSQL and pine, along with everything else, should comply with FHS;
> > then there will be no confusion because everyone will be following the
> > smae standards. Messes arise wh
Vince Vielhaber wrote:
> On Thu, 13 Feb 2003, Lamar Owen wrote:
>
> > On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
> > > Actually FHS says the opposite. If the distribution installs PostgreSQL
> > > then the config files belong in /etc/postgresql. If the admin does then
> > > they
Lamar Owen wrote:
> > First, a few conclusions:
>
> > We can't use /var/run because we need the postmaster to create
> > those, and it isn't root.
>
> It isn't without precedent to have a directory under /var/run. Maybe
> /var/run/postgresql. Under this one could have a uniquely named
Bruce Momjian wrote:
> I don't think separate params for each config file is good. At the
> most, I think we will specify the configuration _directory_ for all the
> config files, perhaps pgsql/etc, and have pgdata default to ../data, or
> honor $PGDATA. That might be the cleanest.
>
> Of course
On Thursday 13 February 2003 20:09, Bruce Momjian wrote:
> Lamar Owen wrote:
> > This isn't the same environment, Bruce, that you got into back when it
> > was still Postgres95.
> So you are saying this isn't my grandma's database anymore. :-)
I actually thought of saying it that way, too. :-)
Lamar Owen wrote:
> This isn't the same environment, Bruce, that you got into back when it was
> still Postgres95. We are in the big leagues OS-wise, and we need to act like
> it. Assuming that we are a 'userspace' program (which is a misnomer anyway,
> as _anything_ non-kernel is 'userspace')
On Thu, Feb 13, 2003 at 05:59:17PM -0500, Robert Treat wrote:
> On Thu, 2003-02-13 at 15:08, mlw wrote:
> > Stephan Szabo wrote:
> >
> > On Thu, 13 Feb 2003, mlw wrote:
> >
> > I have absolutely no problem debating and augmenting the feature. None
> > what so ever, I am more pushing to get moment
On Thursday 13 February 2003 18:41, Vince Vielhaber wrote:
> On Thu, 13 Feb 2003, Lamar Owen wrote:
> > PostgreSQL is as critical as PHP, Apache, or whatever other package is
> > being backended by PostgreSQL. If the package is provided by the
> > distributor, consider it part of the OS. If it is
On Thu, 13 Feb 2003, Lamar Owen wrote:
> On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
> > Actually FHS says the opposite. If the distribution installs PostgreSQL
> > then the config files belong in /etc/postgresql. If the admin does then
> > they belong in /usr/local/etc/postgresql
On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
> Actually FHS says the opposite. If the distribution installs PostgreSQL
> then the config files belong in /etc/postgresql. If the admin does then
> they belong in /usr/local/etc/postgresql. FHS is out of their tree. If
> PostgreSQL or
On Thursday 13 February 2003 17:53, Bruce Momjian wrote:
> Oliver Elphick wrote:
> > What your comments strongly suggest to me is that projects like
> > PostgreSQL and pine, along with everything else, should comply with FHS;
> > then there will be no confusion because everyone will be following th
Robert Treat wrote:
On Thu, 2003-02-13 at 14:51, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configura
On 13 Feb 2003, Oliver Elphick wrote:
> What your comments strongly suggest to me is that projects like
> PostgreSQL and pine, along with everything else, should comply with FHS;
> then there will be no confusion because everyone will be following the
> smae standards. Messes arise when people ig
Bruce Momjian wrote:
Robert Treat wrote:
IIRC the postmaster.pid file should be in /var/run according to FHS, I'm
not sure about postmaster.opts though...
Again, if we're going to make a change, let's make sure we think it
through.
Can non-root write to /var/run?
On Thu, 2003-02-13 at 15:08, mlw wrote:
> Stephan Szabo wrote:
>
> Re-read my statement and yours about the case you were mentioning. ;)
>
> Sure, putting the files in /etc lets you find them easily. However, if
>
> you're doing things like finding configuration made by someone else and
>
> sa
Robert Treat wrote:
> IIRC the postmaster.pid file should be in /var/run according to FHS, I'm
> not sure about postmaster.opts though...
>
> Again, if we're going to make a change, let's make sure we think it
> through.
Can non-root write to /var/run?
--
Bruce Momjian
Oliver Elphick wrote:
> What your comments strongly suggest to me is that projects like
> PostgreSQL and pine, along with everything else, should comply with FHS;
> then there will be no confusion because everyone will be following the
> smae standards. Messes arise when people ignore standards; w
On Thu, 2003-02-13 at 14:51, mlw wrote:
>
>
> Robert Treat wrote:
>
>
> On Thu, 2003-02-13 at 12:13, mlw wrote:
>
>
>
> My patch only works on the PostgreSQL server code. No changes have been
>
> made to the initialization scripts.
>
>
>
> The patch declares three extra configuration f
On Thu, 2003-02-13 at 14:43, Bruce Momjian wrote:
> Robert Treat wrote:
> > On Thu, 2003-02-13 at 12:13, mlw wrote:
> > >
> > > My patch only works on the PostgreSQL server code. No changes have been
> > > made to the initialization scripts.
> > >
> > > The patch declares three extra configuratio
On Thu, 2003-02-13 at 14:28, Bruce Momjian wrote:
> Robert Treat wrote:
> > On Thu, 2003-02-13 at 14:06, mlw wrote:
> > >
> > > I will be resubmitting my patch for the 7.3.2 tree.
> > >
> >
> > I'm no core developer, but surely this wont be included in the 7.3.x
> > branch. Any change needs to b
On Thu, 2003-02-13 at 21:21, Vince Vielhaber wrote:
> I certainly wasn't trying to provoke anything. It just seems odd to me
> that when the distribution installs a package and places it's config files
> in /etc and later the admin happens to upgrade by the instructions with
> the package, it's ac
> All I see here is an arbitrary break with our past practice. I do
> not see any net improvement.
Well, given that there's a trend to make PostgreSQL more usable, I can
say with absolute certainty, that an FAQ that I get about once a week
is (and granted only from new users) "where is the postg
scott.marlowe wrote:
These are not issues at all. You could put the configuration file
anywhere, just as you can for any UNIX service.
postmaster --config=/home/myhome/mydb.conf
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get t
On Thu, 13 Feb 2003, mlw wrote:
>
>
> Christopher Browne wrote:
>
> >In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
> >
> >>On Wed, 12 Feb 2003, Peter Bierman wrote:
> >>
> >>>What do you gain by having the postmaster config and the database
> >>>data live in different lo
On 13 Feb 2003, Oliver Elphick wrote:
> On Thu, 2003-02-13 at 18:45, Bruce Momjian wrote:
> > Oliver Elphick wrote:
> > > On Thu, 2003-02-13 at 17:52, Vince Vielhaber wrote:
> > > > Seems to me that if FHS allows such a mess, it's reason enough to avoid
> > > > compliance. Either that or those of
Peter Eisentraut wrote:
mlw writes:
AFAIK it wasn't actually done. It was more of a, "we should do something
different" argument. At one point it was talked about rewriting the
configuration system to allow "include" and other things.
The core of the problem was, and
mlw writes:
> AFAIK it wasn't actually done. It was more of a, "we should do something
> different" argument. At one point it was talked about rewriting the
> configuration system to allow "include" and other things.
The core of the problem was, and continues to be, this: If you move
postgresql.
I don't see why we can't keep everyone happy and let the users choose the
setup they want. To wit, make the following, probably simple, changes:
1) Have postgresql default to using /etc/postgresql.conf
2) Add a setting in postgresql.conf specifying the data directory
3) Change the meaning of -D t
On 13 Feb 2003, Martin Coxall wrote:
>
> > Well, to the extent that you're serious, you understand that
> > a lot of people feel that /usr/local should be reserved for
> > stuff that's installed by the local sysadmin, and your
> > vendor/distro isn't supposed to be messing with it.
> >
> > Wh
Stephan Szabo wrote:
On Thu, 13 Feb 2003, mlw wrote:
Stephan Szabo wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to
Bruce Momjian wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
hbafile= '/e
On Thu, 13 Feb 2003, mlw wrote:
> Stephan Szabo wrote:
> >>>On Thu, 2003-02-13 at 09:23, mlw wrote:
> I deal with a number of PG databases on a number of sites, and it is a
> real pain in the ass to get to a PG box and hunt around for data
> directory so as to be able to administer th
On Thu, 2003-02-13 at 19:30, Robert Treat wrote:
> If we're going to do this, I think we need to account for all of the
> files in the directory including PG_VERSION, postmaster.opts,
Not PG_VERSION; that is intimately associated with the data itself and
ought to stay in the data directory.
--
O
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
hbafile= '/etc/postgres/pg_hba.conf'
identfile='/
Robert Treat wrote:
> On Thu, 2003-02-13 at 12:13, mlw wrote:
> >
> > My patch only works on the PostgreSQL server code. No changes have been
> > made to the initialization scripts.
> >
> > The patch declares three extra configuration file parameters:
> > hbafile= '/etc/postgres/pg_hba.conf'
> >
Bruce Momjian wrote:
Well, in a sense, it trades passing one parameter, PGDATA, for another.
I see your point that we should specify configuration first, and let
everything pass from there. However, it does add extra configuration
parameters, and because you still need to specify/create pgdat
On Thu, 2003-02-13 at 12:13, mlw wrote:
>
> My patch only works on the PostgreSQL server code. No changes have been
> made to the initialization scripts.
>
> The patch declares three extra configuration file parameters:
> hbafile= '/etc/postgres/pg_hba.conf'
> identfile='/etc/postgres/pg_ident.co
Robert Treat wrote:
> On Thu, 2003-02-13 at 14:06, mlw wrote:
> >
> > I will be resubmitting my patch for the 7.3.2 tree.
> >
>
> I'm no core developer, but surely this wont be included in the 7.3.x
> branch. Any change needs to be made against CVS head.
I assume he meant he will repost his 7.3
On Thu, 2003-02-13 at 14:06, mlw wrote:
>
> I will be resubmitting my patch for the 7.3.2 tree.
>
I'm no core developer, but surely this wont be included in the 7.3.x
branch. Any change needs to be made against CVS head.
Robert Treat
---(end of broadcast)-
mlw wrote:
> >It doesn't have anything to do with "not-invented-here", which is a
> >common refrain by people who don't like our decisions, like "Why don't
> >you use mmap()? Oh, it's because I thought of it and you didn't". Does
> >anyone seriously believe that is the motiviation of anyone in th
On Thu, 2003-02-13 at 18:45, Bruce Momjian wrote:
> Oliver Elphick wrote:
> > On Thu, 2003-02-13 at 17:52, Vince Vielhaber wrote:
> > > Seems to me that if FHS allows such a mess, it's reason enough to avoid
> > > compliance. Either that or those of you who build for distributions are
> > > making
On Thu, 2003-02-13 at 18:45, Bruce Momjian wrote:
> Now, on to this configuration discussion. Seems moving the config file
> out of $PGDATA requies either:
>
> 1) we specifiy both the config directory and the data directory on
> postmaster start
>
> 2) we specify th
Bruce Momjian wrote:
Oliver Elphick wrote:
On Thu, 2003-02-13 at 17:52, Vince Vielhaber wrote:
Seems to me that if FHS allows such a mess, it's reason enough to avoid
compliance. Either that or those of you who build for distributions are
making an ill advised ch
Oliver Elphick wrote:
> On Thu, 2003-02-13 at 17:52, Vince Vielhaber wrote:
> > Seems to me that if FHS allows such a mess, it's reason enough to avoid
> > compliance. Either that or those of you who build for distributions are
> > making an ill advised change. Simply because the distribution mak
On Thu, 2003-02-13 at 17:52, Vince Vielhaber wrote:
> Seems to me that if FHS allows such a mess, it's reason enough to avoid
> compliance. Either that or those of you who build for distributions are
> making an ill advised change. Simply because the distribution makes the
> decision to add Postg
On 13 Feb 2003, Oliver Elphick wrote:
> On Thu, 2003-02-13 at 12:00, Vince Vielhaber wrote:
> > > Which means if the the vendor installed Postgresql (say, the
> > > Red Hat Database) you'd expect config files to be in /etc.
> > > If the postgresql is compiled from source by local admin,
> > > you
On Thu, 2003-02-13 at 12:00, Vince Vielhaber wrote:
> > Which means if the the vendor installed Postgresql (say, the
> > Red Hat Database) you'd expect config files to be in /etc.
> > If the postgresql is compiled from source by local admin,
> > you might look somewhere in /usr/local.
>
> Then why
On Thu, 2003-02-13 at 13:32, Christopher Browne wrote:
> > Everybody has room in /etc for another 10K of data. Where you have
> > room for something that might potentially be a half terrabyte of
> > data, and is not infrequently several gigabytes or more, is pretty
> > system-depenendent.
>
> Ah,
Stephan Szabo wrote:
On Thu, 13 Feb 2003, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get to a PG box and hunt around
On Thu, 13 Feb 2003, mlw wrote:
>
>
> Robert Treat wrote:
>
> >On Thu, 2003-02-13 at 09:23, mlw wrote:
> >
> >
> >>I deal with a number of PG databases on a number of sites, and it is a
> >>real pain in the ass to get to a PG box and hunt around for data
> >>directory so as to be able to administe
Bruno Wolff III wrote:
On Thu, Feb 13, 2003 at 09:23:20 -0500,
mlw <[EMAIL PROTECTED]> wrote:
Personally, however, I think the configuration issue is a no-brainer and
I am amazed that people are balking. EVERY other service on a UNIX box
is configured in this way, why not do
Robert Treat wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get to a PG box and hunt around for data
directory so as to be able to administer the system. What's really
annoying is when
On Thu, 2003-02-13 at 09:23, mlw wrote:
> I deal with a number of PG databases on a number of sites, and it is a
> real pain in the ass to get to a PG box and hunt around for data
> directory so as to be able to administer the system. What's really
> annoying is when you have to find the data dire
On Thu, Feb 13, 2003 at 09:23:20 -0500,
mlw <[EMAIL PROTECTED]> wrote:
>
> Personally, however, I think the configuration issue is a no-brainer and
> I am amazed that people are balking. EVERY other service on a UNIX box
> is configured in this way, why not do it this way in PostgreSQL? The
>
On Thu, Feb 13, 2003 at 15:03:09 +,
"Nigel J. Andrews" <[EMAIL PROTECTED]> wrote:
>
> Is everyone forgetting that wherever the configuration file is stored and
> whether or not it needs a command line argument to specify it the database is
> not going to start up automatically unless at leas
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instances
running
On Thursday 13 February 2003 10:03, Tom Lane wrote:
> mlw <[EMAIL PROTECTED]> writes:
> > Here is the test, configure a server, with sendmail, named, apache, and
> > PostgreSQL. Tell me which of these systems doesn't configure right.
> AFAIK, only one of those four is designed to support multiple
On Thu, 13 Feb 2003, mlw wrote:
> Tom, I just don't understand why this is being resisted so vigorously.
> What is wrong with starting PostgreSQL as:
>
> postmaster -C /etc/postgresql.conf
>
> UNIX admins would love to have this as a methodology, I don't think you
> can deny this, can you? I,
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instances
running
mlw <[EMAIL PROTECTED]> writes:
> Here is the test, configure a server, with sendmail, named, apache, and
> PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instances
running on a single machine. This is not unrelat
On Thu, 13 Feb 2003, Curt Sampson wrote:
> On Thu, 13 Feb 2003, Christopher Browne wrote:
>
> > 1. It assumes that there is "a location" for "the configuration files
> > for /the single database instance./"
>
> No; it assumes that there's a location for "the default instance." If
> you have
On Thursday 13 February 2003 08:32, Christopher Browne wrote:
> In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
> > Everybody has room in /etc for another 10K of data. Where you have
> > room for something that might potentially be a half terrabyte of
> > data, and is not infr
On Thu, 13 Feb 2003, Christopher Browne wrote:
> 1. It assumes that there is "a location" for "the configuration files
> for /the single database instance./"
No; it assumes that there's a location for "the default instance." If
you have more than one, you could have one default and one elsew
Christopher Browne wrote:
In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
On Wed, 12 Feb 2003, Peter Bierman wrote:
What do you gain by having the postmaster config and the database
data live in different locations?
You can t
> -Original Message-
> From: Christopher Browne [mailto:[EMAIL PROTECTED]]
> Sent: 13 February 2003 13:33
> To: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] location of the configuration files
>
>
> In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) w
In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
> On Wed, 12 Feb 2003, Peter Bierman wrote:
>
>> What do you gain by having the postmaster config and the database
>> data live in different locations?
>
> You can then standardize a location for the configuration files.
>
> Ever
On Wed, 12 Feb 2003, Peter Bierman wrote:
> What do you gain by having the postmaster config and the database
> data live in different locations?
You can then standardize a location for the configuration files.
Everybody has room in /etc for another 10K of data. Where you have
room for something
On Wed, 12 Feb 2003, J. M. Brenner wrote:
>
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> wrote:
>
> > > Okay, here's one: most Unix systems store all of the configuration
> > > files in a well known directory: /etc. These days it's a hierarchy of
> > > directories with /etc as the root of the
> Well, to the extent that you're serious, you understand that
> a lot of people feel that /usr/local should be reserved for
> stuff that's installed by the local sysadmin, and your
> vendor/distro isn't supposed to be messing with it.
>
> Which means if the the vendor installed Postgresql (sa
Before I get started, I should note that it may be a good compromise
to have the data directory be the same as the config file directory,
when neither the config file nor the command line specify something
different. So the changes I think may make the most sense are:
1. We add a new GUC variab
Peter Bierman wrote:
At 12:31 AM -0500 2/13/03, mlw wrote:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do it
At 12:31 AM -0500 2/13/03, mlw wrote:
The idea that a, more or less, arbitrary data location determines
the database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do it.
Isn't the database d
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to d
mlw <[EMAIL PROTECTED]> writes:
> The idea that a, more or less, arbitrary data location determines the
> database configuration is wrong. It should be obvious to any
> administrator that a configuration file location which controls the
> server is the "right" way to do it.
I guess I'm just den
Tom Lane wrote:
Kevin Brown <[EMAIL PROTECTED]> writes:
I assume $PGDATA was around long before GUC?
Yes, it was. But I have not yet seen an argument here that justifies
why $SOMECONFIGDIRECTORY/postgresql.conf is better than
$PGDATA/postgresql.conf. The latter keeps
On Wednesday 12 February 2003 20:37, Christopher Kings-Lynne wrote:
> > Okay, here's one: most Unix systems store all of the configuration
> > files in a well known directory: /etc. These days it's a hierarchy of
> No [snip] - /usr/local/etc. Why can't the Linux community respect
> history
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> wrote:
> > Okay, here's one: most Unix systems store all of the configuration
> > files in a well known directory: /etc. These days it's a hierarchy of
> > directories with /etc as the root of the hierarchy. When an
> > administrator is looking for
> > binaries (he doesn't necessarily have access to the sources that the
> > binaries were compiled from, which is all that matters here).
>
> No goddammit - /usr/local/etc. Why can't the Linux community respect
> history
History? It's the only way to make a read-only / (enforced by
secure-
> Okay, here's one: most Unix systems store all of the configuration
> files in a well known directory: /etc. These days it's a hierarchy of
> directories with /etc as the root of the hierarchy. When an
> administrator is looking for configuration files, the first place he's
> going to look is in
On Wed, 2003-02-12 at 08:24, Kevin Brown wrote:
> Tom Lane wrote:
> > You can only justify it as simpler if you propose hardwiring a value
> > for $SOMECONFIGDIRECTORY ...
>
> Making things simpler from the standpoint of the code isn't the point.
> Making things simpler for the DBA and/or Unix sys
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > I assume $PGDATA was around long before GUC?
>
> Yes, it was. But I have not yet seen an argument here that justifies
> why $SOMECONFIGDIRECTORY/postgresql.conf is better than
> $PGDATA/postgresql.conf.
Okay, here's one: most Unix s
Kevin Brown <[EMAIL PROTECTED]> writes:
> I assume $PGDATA was around long before GUC?
Yes, it was. But I have not yet seen an argument here that justifies
why $SOMECONFIGDIRECTORY/postgresql.conf is better than
$PGDATA/postgresql.conf. The latter keeps all the related files
together. The forme
mlw wrote:
> AFAIK it wasn't actually done. It was more of a, "we should do something
> different" argument. At one point it was talked about rewriting the
> configuration system to allow "include" and other things.
That seems like extreme overkill. The PostgreSQL configuration
mechanism doesn'
I, personally, also think it makes more sense to pass to the postmaster
a configuration file that contains all the rest of the information about
the database system, including the disk locations of the various data
directories and whatnot.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2
Robert Treat wrote:
I'm going to be lazy and ask if you can post what the better solution
that was coming was (or a link to the thread). While I'll grant you that
the "it's coming" argument is pretty weak after two releases, that fact
that it may have been a better solution could still hold up.
On Tue, 2003-02-11 at 13:44, mlw wrote:
> The debate on the configuration file sparked a memory of an old patch I
> submitted in 7.1 days.
>
> One of the things I do not like about PostgreSQL is, IMHO, is a
> backwards configuration process. Rather than specify a data directory,
> the administr
101 - 188 of 188 matches
Mail list logo
