Re: chosing a database name

pgsql-general-owner@postgresql.org wrote on 07/13/2005 02:59:02 PM:

> On Wed, Jul 13, 2005 at 12:53:15PM -0400, Alvaro Herrera wrote:
>
> > > we are developing GNUmed, a medical practice management
> > > application running on PostgreSQL (you want your medical
> > > data to be hosted by something reliable, don't you ;-)  We
> > > are putting out our first release sometime in the next two
> > > weeks.
> > >
> > > The idea is to name the production database "gnumed0.1" for
> > > version 0.1 (gnumed0.2 etc for upcoming releases). I do
> > > realize the "." may force me to quote the database name in,
> > > say, a CREATE DATABASE call.
> >
> > I doubt you'll have any problems with the tools, but the quoting may
> > prove painful.  Why not replace the dot with an underscore? gnumed0_1
> Good suggestion. I will try to find a name that a) makes the
> version tag unambigous and b) does not require quoting.
>
> My main concern, however, was whether the *approach* is
> sound, eg using a separate database name per release or IOW
> version. One way would be to use the database name "gnumed"
> regardless of release, another way would be to use
> "gnumedX_Y" for release X.Y. I wonder whether the latter
> approach has any drawbacks people might think of regarding
> release management etc.

I think a better approach is to handle configuration management with a
table in each schema.  Update the schema, update the table.  This works
well with automating database upgrades as well, where upgrades are written
as scripts, and applied in a given order to upgrade a database from release
A to C, or A to X, depending on when it was archived.  A script naming
convention (e.g. numerical) can determine order, and each script can
register in (write a line to) the configuration management table.  This
allows for error analysis, among other things.

Rick

>
> Thanks,
> Karsten
> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly