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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
