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

[Ian Haywood]

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