Robert Haas <robertmh...@gmail.com> writes: > So I guess really can't get worked up about the idea of propagating > this information through the type system. Even suppose we eventually > take the steps you suggesting and make it so that varchar(30) || > varchar(40) yields varchar(70). What good is that? Why would anyone > care?
People have complained that we don't follow the spec on this. Not many people, perhaps, and it's certainly arguable that fixing this will be far more trouble than it's worth. But there is a constituency that cares --- mainly people who use client-side code that tends to fall over if it doesn't see a suitable maxlength attached to query result columns. The first example I came across in the archives was http://archives.postgresql.org/pgsql-sql/2002-06/msg00235.php [ pokes around a bit more ... ] Hm, I don't see any *recent* examples. Maybe all that code has gotten fixed? Nah ... > What would actually be really nice is the ability to have > parameterized types (like list-of-<some type>, > unordered-set-of-<type>, hash-with-keys-of-<some > type>-and-values-of-<some type>, function-taking-arguments-of-<various > types>-returning-<some type>) which would let us do all kinds of neat > things - but I don't see how improving support for typmods gets us any > closer to that. Well, we could possibly implement hacks like the current one for anonymous record types. But SQL isn't intended as a language for manipulating arbitrary data types, and I think trying to make it do stuff like the above will be an exercise in masochism. typmod is mainly intended for tweaking the properties of base types, and it seems fairly useful for that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers