gnumed-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]