Vincenzo Romano <vincenzo.rom...@notorand.it> wrote: > 2010/10/7 Stephen Frost <sfr...@snowman.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers