On Sat, Feb 18, 2006 at 07:55:23PM -0800, Jim Busser 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. Ah, I see. Yes, you are right, that can certainly be a problem down the road ! I didn't think of that...
> 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? That's one reason. Another reason would be that there *should not* be any such characters in those fields -- until a counter-example is shown to exist. > >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? Exactly, that's what they are intended to do. I'll add the constraints. 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
