Karsten Hilbert wrote: > 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 ? 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. Display and compare functions should be easy on PL/PgSQL, the display function can use the existing server locale settings so everyone sees the day-month-year ordering they expect. (IMHO in English-speaking context we should always name the month anyway to avoid any potential mis-understanding)
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? 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. Ian Ian _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
