On sön, 2010-10-31 at 14:30 -0400, Robert Haas wrote: > It's true that if the ostensible maximum length of a string or the > precision of a numeric get lost somewhere on their path through the > system, probably nothing terribly awful will happen. The worst case > is that those values won't be enforced someplace where the user might > expect it, and that's probably avoidable in most practical cases by > adding an appropriate cast. I'm not sure whether it'll also be true > for collation, because that affects comparison semantics, and getting > the wrong comparison semantics is worse than failing to enforce a > maximum length.
I think the problem is rather that we don't have a good answer for what to do about propagating and combining typmods in all the cases. What should varchar(10) || varchar(15) be? Probably varchar(25). What about numeric(10) + numeric(15)? What about numeric(10) * numeric(15)? etc. If we had a generalized answer to that, it might be possible to implement it in the right places. (I'd guess it would be about half of the size of the current collation patch.) > Long story short, I'm inclined to view any data structure that is > carrying only the type OID with great suspicion. If the additional > information isn't needed today, it may well be tomorrow. Maybe, but again this patch doesn't solve that. It just combines existing OID + typmod into a single structure. It doesn't add typmods where there were none before. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
