Re: chosing a database name

From: Richard_D_Levine(at)raytheon(dot)com
To: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-general-owner(at)postgresql(dot)org
Subject: Re: chosing a database name
Date: 2005-07-13 20:53:26
Message-ID: OFDD6BE20E.B0B4F292-ON0525703D.0072474F-0525703D.0072C17A@ftw.us.ray.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

pgsql-general-owner(at)postgresql(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2005-07-13 21:04:34 Re: Standalone Parser for PL/pgSQL
Previous Message David Esposito 2005-07-13 20:53:25 Re: index bloat