pgsql-general-owner@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx so that your
> message can get through to the mailing list cleanly
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
