On Wed, Nov 25, 2009 at 1:02 PM, Merlin Moncure <mmoncure@gmail.com> 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.
