W dniu 11.05.2014 22:01, David G Johnston pisze:
On Sun, May 11, 2014 at 2:08 PM, Tim Kane [via PostgreSQL] <[hidden
email] </user/SendEmail.jtp?type=node&node=5803579&i=0>>wrote:
[------------------]
This is basically what I intended to describe in "option 2"...without
the benefit of ever having really read the SQL standard.
So the planner would have to know that, for a given table, the
generation expression results in a constant - would likely in fact
have to be a constant expression like, assuming a non-number value,
='column_value', where the "=" sign indicates that this is a
generation expression and not a stored value (like default behaves
currently).
wouldn't it be ways better, if the constraints for partitioning by
inharitance were set at the "master" table, instead of the way it's
currently done at the inharited tables (as exclusive CHECK-s there)?
I mean a constraint like a "function(table columns) reutrning table_name
or tablespace_name of the actual target table"?
<start preudocode>
create table master (a int, b int, c int);
create table table_a (inharits master);
create table table_b (inharits master);
create function(a,b) returns text as $$ if a > b then return "table_a"
else return "table_b"; end if; end $$
... or:
create function(a,b) returns tablespace as $$ if a > b then return
tablespace("table_a") else return tablespace("table_b"); end if; end $$
alter table master add constraint "partitioning" check/select/route
function(a,b);
<end pseudocode>
-R
