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 or she is already working on that part
of PostgreSQL, someone already made a plan and checked whether the request is
feasible to 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 too limiting, 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 of data into the database itself, so
just having to care for changes at one place and making sure data and data
domains of valid data are tightly integrated, which I favor.
Regards,
Ralph
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
