Robert Haas <robertmhaas@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