paul_t100@xxxxxxxxxxx (Paul Taylor) writes: > If instead you have to run a database standalone, then you do hit > configurations problems, not only platform specific issues but also > people bloody mindness about creating databases with different names > and database users : whatever the documentation says which has to be > accounted for in tests. To pretend there are no issues with setting up > a database is unrealistic. Actually, it seems to me that these issues are there, regardless. I have been setting up regression tests lately :-), and what I've had to do is to set up scripts to manage setting up databases. I haven't gone so far as demanding to start out with "initdb"; I assume the presence of a functioning cluster. Even with that, since there are ~4 databases to set up, I've got scripts filled with stuff like: (Not literally excerpted; this is an excerpt from... http://main.slony.info/viewcvs/viewvc.cgi/slony1-engine/tests/settings.ik?view=log) DB1=${DB1:-"slonyregress1"} HOST1=${HOST1:-"localhost"} USER1=${USER1:-${PGUSER:-"postgres"}} WEAKUSER1=${WEAKUSER1:-${WEAKUSER:-${PGUSER:-"weakuser"}}} PORT1=${PORT1:-${PGPORT:-"5432"}} PGBINDIR1=${PGBINDIR1:-${PGBINDIR:-"/usr/local/pgsql/bin"}} DB2=${DB2:-"slonyregress2"} HOST2=${HOST2:-"localhost"} USER2=${USER2:-${PGUSER:-"postgres"}} WEAKUSER2=${WEAKUSER2:-${WEAKUSER:-${PGUSER:-"weakuser"}}} PORT2=${PORT2:-${PGPORT:-"5432"}} PGBINDIR2=${PGBINDIR2:-${PGBINDIR:-"/usr/local/pgsql/bin"}} DB3=${DB3:-"slonyregress3"} HOST3=${HOST3:-"localhost"} USER3=${USER3:-${PGUSER:-"postgres"}} WEAKUSER3=${WEAKUSER3:-${WEAKUSER:-${PGUSER:-"weakuser"}}} PORT3=${PORT3:-${PGPORT:-"5432"}} PGBINDIR3=${PGBINDIR3:-${PGBINDIR:-"/usr/local/pgsql/bin"}} DB4=${DB4:-"slonyregress4"} HOST4=${HOST4:-"localhost"} USER4=${USER4:-${PGUSER:-"postgres"}} WEAKUSER4=${WEAKUSER4:-${WEAKUSER:-${PGUSER:-"weakuser"}}} PORT4=${PORT4:-${PGPORT:-"5432"}} PGBINDIR4=${PGBINDIR4:-${PGBINDIR:-"/usr/local/pgsql/bin"}} I don't think things would be made notably worse if I included "initdb" in my process. That would add a few extra steps, and the mandate that I set up some configuration for: a) pg_hba.conf b) postgresql.conf c) where to find initdb This would all be somewhat simpler if I were using (say) SQLite. But the burdens aren't spectacularly heavy. And if you choose to run the database in an "embedded-ish" fashion, then you get to be somewhat "bloodyminded" about how your cluster gets set up. I've had the scenario where I had to tell QA (with somewhat more diplomacy than this ;-)): "If you're going to set up databases on the same backend, you can't use the same users I have coded with. If you *DO* get bloody-minded about it, and this causes some inconvenience, then it's right well YOUR problem that you're not following the stipulations documented for the system." I'm not going to try to force *stupid* constraints on people, but it doesn't seem to be "out there" to have some details stipulated. I'll note that in my favorite "common-preferences.sh" file, while practically everything can be configured, if one were so dumb as to ask to do so, enough defaults get inherited (via the shell :- construct) that *USUALLY*, the only values that people need to configure are: a) PGBINDIR, the directory where your favorite PostgreSQL psql client lives, and b) PGPORT, the port where your favorite cluster answers I'm pretty happy with this; *EVERYTHING* may be overridden, if need be, but it is typically sufficient to set those two environment variables and have things "just work." -- output = reverse("ofni.sesabatadxunil" "@" "enworbbc") http://linuxdatabases.info/info/rdbms.html str->str_pok |= SP_FBM; /* deep magic */ s = (unsigned char*)(str->str_ptr); /* deeper magic */ -- Larry Wall in util.c from the perl source code -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
