Re: (check) constraints on composite type

Hi David!

> Sorry for not answering the main question but you really need to avoid
> phrases like "near future".  That said, new features are only released
> during major releases and so at best you would have to wait for 9.2 which is
> probably 9+ months out since 9.1 was just recently released.  The better
> question is whether 9.2 is likely to have what you need or whether it has a
> chance to be during 9.3 (1.5+ years out).  More generically the question is
> whether anyone is currently working on the feature.

Thanks alot for your input on that issue. I really appreciate it. -

However I posed my question using that wording intentionally, so it is open to any input, may it that someone states he
orshe is already working on that part of PostgreSQL, someone already made a plan and checked whether the request is
feasibleto add or any other decisions on that topic, that were probably made and I missed or were not published. "Near
future"for me means getting all possible input, not referring to a particular time line. If one tells me "it is
planned,no deadline given" that's as fine for me as "no plans, no idea" or "March, 12th, this year". 
Understanding your point, I found posing the question using "whether anyone is currently working on the feature" far
toolimiting, probably guiding the question into the wrong direction, like pushing someone to look into it between the
lines- in the sense of "why the heck is PostgreSQL lacking that feature of utmost importance?" - which I didn't intent. 

Now back to the point of question:

> You do have other options depending on how critical such a feature is to
> you.  There are possibly workarounds that can be implemented or you can
> always commission the work and request a back-port to 9.1 with future
> inclusion into 9.2 (or 9.3 is feature freeze has taken effect).

Let's assume I have three fields in my custom type:

field1 varchar(4)   // or text
field2 smallint
field3 char(1)      // or text

Now I want to add a complex check constraint involving the combination of those three fields, written in pseudo code:

field1 IN ('A') && field2 BETWEEN 1 AND 120 && field3 IS NULL
field1 IN ('B') && field2 BETWEEN 1 AND 40 && field3 IS NULL
field1 IN ('TFnr') && field3 BETWEEN 1600 AND 2200 && field3 IN ('a', 'b', 'c')
field1 IS NULL & field2 = 1 & field3 IN ('a'..'z') OR field3 IS NULL
...            & field2 = 2 & field3 IN ('a'..'h') OR field3 IS NULL
...            & field2 = 3 & field3 IN ('a'..'o', 'Z') OR field3 IS NULL

and so on (the problem is actually far more complex, just to give a hint of…). My point is putting all the validation
ofdata into the database itself, so just having to care for changes at one place and making sure data and data domains
ofvalid data are tightly integrated, which I favor. 

Regards,
     Ralph