On Wed, Nov 25, 2009 at 1:02 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: > > IMO, ('abc', 'def')::foo honestly should honor constraints on foo. > This probably isn't controversial. So who do we need to convince to make this happen? The things we could do with this kick ass. Maybe the details of the file I linked are wrong, but just the idea of a short script that we could settle on as a standard... (on the other hand, I just saw a varchar(30) for a column named birth_date at work the other day, and we already have a data type perfect for that, so maybe it wouldn't help at all.) > Since starting with 8.4 you can index composite types directly, you > could possibly make a case that a lot of built in postgresql types, > especially geometric types, could be reimplemented as composites, and > toss a lot of code that backs the geo types such as the various in/out > routines. I don't think this will ever happen for various reasons > (backwards compatibility and possibly efficiency for example), but > it's fun to think about. The best way to do complex validation based > on type in postgresql today is in C if you don't want to add > constraints wherever the type is used. Well, my understanding is that anything in C means that the superuser has to declare/define it. That makes things slightly more inconvenient, but isn't a dealbreaker. Are there any examples of this anywhere? Could someone cook one up for me? The docs are pretty thin on this subject, or I'm looking in the wrong places. Thanks, John O. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general