Karsten Hilbert wrote: > Hello all, > > we allow the user to associate a point in time with any > document in our archive. This field is later used for quick > visual selection of the relevant documents a doctor is > looking for, eg "8/2001 neurological discharge letter" where > the "8/2001" is the part coming from the date field. > > Currently, this field is free text such as not to constrain > whatever precision of date is known, eg 2001, 8/2001, > 2001/8/27, 2001/8/27 @ 15:22:33 are all possible inputs. > However, "total crap" is valid input, too, currently, which > does not lend itself to useful post-processing. > > Making it a real timestamp isn't really an option due to > medical realities. > > I am not sure about the stability of Ian's attempt at a > fuzzy timestamp type. > > So, what do people think we should allow as input in terms > of string parsing. I am thinking of (d=digit): > > 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. It gets hard when you want to order entries and compare (which you often will) as doing this on free text gets slow.
The proper way is to implement a new Postgres type which holds a timestamp plus and accuracy field (one byte). Operators for comparsion ad equality can be written, which becomes fast and easy. This is all doable, not too hard, and I'm happy to volunteer. 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. 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. Ian _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
