[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Clinicians: document content date in archive
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Clinicians: document content date in archive |
Date: |
Wed, 10 May 2006 14:22:51 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
On Wed, May 10, 2006 at 09:43:15PM +1000, Ian Haywood wrote:
> However this means we would now be postgres >= 8.0. Are we psychologically
> prepared?
> Is anyone still on 7.x?
...
> Parsing is slightly messier than it would be in python (because of how regexp
> subexpressions work) but still doable
> What's the policy on PL/Python now?
Well, I consider Debian stable (Sarge, that is, currently)
to be our "reference" platform:
#---------------------------------------------------
postgresql:
Installiert:7.5.19
Mögliche Pakete:7.5.19
Versions-Tabelle:
*** 7.5.19 0
990 ftp://ftp.gwdg.de testing/main Packages
100 /var/lib/dpkg/status
7.4.7-6sarge1 0
500 ftp://ftp.gwdg.de stable/main Packages
500 ftp://ftp.de.debian.org stable/main Packages
postgresql-8.0:
Installiert:(keine)
Mögliche Pakete:8.0.4-4
Versions-Tabelle:
8.0.4-4 0
990 ftp://ftp.gwdg.de testing/main Packages
postgresql-8.1:
Installiert:(keine)
Mögliche Pakete:8.1.3-4
Versions-Tabelle:
8.1.3-4 0
990 ftp://ftp.gwdg.de testing/main Packages
postgresql-plpython-7.4:
Installiert:1:7.4.9-2
Mögliche Pakete:1:7.4.9-2
Versions-Tabelle:
*** 1:7.4.9-2 0
990 ftp://ftp.gwdg.de testing/main Packages
100 /var/lib/dpkg/status
#---------------------------------------------------
So, pl/python is fine, PostgreSQL > 7.4 is not (yet). Etch
(testing) is rumored to become stable this year, though.
> > Yes, but maybe it need not be a whole new type with bells
> > and all ? Perhaps we can get away with a *composite* type
> > grouping a "timestamp with timezone" and an "accuracy field"
> > (byte) ? This might be doable entirely in SQL/plpgsql ?
> For some reason I believed composite types can't be used as
> column types, but the docs state clearly they can, so, yes
> composite seems the best option here.
Another point to consider is that we will then need code to
teach pyPgSQL about the new type. Which is doable.
I wonder whether "taggedtypes" will help any.
> Also, their seems to be no reason why we can't use CREATE OPERATOR here, the
> docs use C functions as an example
> but don't say you have to, I'll experiment and report back.
I recall people on the pg lists to post examples.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: [Gnumed-devel] Clinicians: document content date in archive, James Busser, 2006/05/08
Re: [Gnumed-devel] Clinicians: document content date in archive, James Busser, 2006/05/08