Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it> wrote:
> 2010/10/7 Stephen Frost <sfrost(at)snowman(dot)net>:
>> Yes, that would be the problem. Proving something based on
>> expressions is alot more time consuming and complicated than
>> being explicitly told what goes where.
>
> Consuming computing resources at DDL-time should be OK if that
> will lead to big savings at DML-time (run-time), my opinion. It'd
> be just like compile time optimizations.
I think something you haven't entirely grasped is how pluggable
PostgreSQL is -- you can not only define your own functions in a
wide variety of languages (including C), but your own data types,
operators, casts, index strategies, etc. Determining, even at DDL
time that even a built-in datatype's expression is or isn't useful
in partitioning could be quite painful in the absence of syntax
specifically geared toward partitioning. If there's a CHECK
constraint on a polygon column to ensure that it isn't a concave
polygon, you might be facing a lot of work to know whether it's
involved in partitioning. Now imagine that a CHECK constraint is on
a column with a user defined type and uses the @%!! operator and
that the user has changed some of the allowed implicit casts used in
the expression.
While this flexibility is a great strength of PostgreSQL, it makes
some things more difficult to implement than they would be in more
limited database products.
-Kevin