Re: [Gnumed-devel] catching errors in an app

[J Busser]

At 7:51 PM +0100 2/18/06, Karsten Hilbert wrote:
> We need to be very careful here not to jump to invalid
> conclusions. The postal system constraints you mention have
> nothing to do with storing the data itself.

If CR/LF/FF were permitted to be stored with data i.e. inside a 
column, couldn't such characters frustrate programmatic efforts to 
present the data in the way needed? That is all that I meant.

Is it proposed to be added here (but not everywhere) partly because 
it is the likeliest point where users like secretaries might 
type/input such characters -- and/or the likeliest situation where 
these characters risk being imported among data from a legacy or 
interoperating app?

> field called "street" or "town" is sufficiently fine-grained
> for *any* postal system to be able to say: This field is
> *never* supposed to contain any LF/CR ?... I was asking you
> guys to reinforce my suspicion with your experience before
> I put this constraint into the database itself.

FWIW I agree. Presumably aux_street, addendum, urb and suburb can 
fill the other needs an address might have?