Re: [Gnumed-devel] Clinicians: document content date in archive

[Karsten Hilbert]

On Sun, May 07, 2006 at 12:58:19PM +1000, Ian Haywood wrote:

> >  dddd - year
> >  d/dddd or dd/dddd - month/year
> >  dddd/dd/dd - year/month/day
> >  dddd/dd/dd hh:mm:ss - year/month/day hour:minutes:seconds
> > 
> > Do you think this will suffice ?
> I think so. You can write triggers to enforce this with regular expressions.
That was my intent hence the question.

> It gets hard when you want to order entries and compare (which you often 
> will) as doing this on free text gets slow.
Hm, order/compare is the intent, eventually :-(

> The proper way is to implement a new Postgres type which holds a timestamp 
> plus
> and accuracy field (one byte).
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 ?

> This is all doable, not too hard, and I'm happy to volunteer.
I'd be excited to have you explore the composite type approach.

> The downside: AFAIK it has to be done in C, which means compiling, which is 
> going to be a new experience
> for some and potentially a right royal PITA across the board.
It is rumored providing out-of-tree precompiled stuff has
gotten easier.

> The 'halfway-house' is a pair of fields: timestamp and a single constrained 
> char for accuracy. Fast
> sorting on the timestamp, plus some PL/SQL functions to compare and produce a 
> printable version.
Yep, and if we could wrap that up into a composite type we'd
be 3/4th there.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346