Robert Haas <robertmh...@gmail.com> writes: > Right. I'm not surprised that relpartbound uses those node types. I > *am* surprised that pg_get_expr() is expected to be able to handle > them. IOW, they ARE node trees, consonant with the fact that the > column type is pg_node_tree, but they're NOT expressions.
I'm not sure why you're astonished by that, considering that psql has applied pg_get_expr to relpartbound since f0e44751d, which was the same commit that put code into ruleutils.c to make pg_get_expr work on relpartbounds. It seems a bit late to change our minds on this; and anyway, if pg_get_expr didn't handle them, we'd just need to invent another function that did. > Alternatively, maybe pg_get_expr() should just fail and tell you that > this is not an expression, and if you want to see what's in that > column, you should use the SQL-callable functions specifically > provided for that purpose (pg_get_partkeydef, I think). pg_get_partkeydef does something different. regression=# select pg_get_expr(relpartbound,oid) from pg_class where relname = 'beta_neg'; pg_get_expr ---------------------------------- FOR VALUES FROM ('-10') TO ('0') (1 row) regression=# select pg_get_partkeydef('beta_neg'::regclass); pg_get_partkeydef ------------------- RANGE (b) (1 row) > I don't know > why it should be legitimate for pg_get_expr() to just assume that any > random node tree it gets handed must be an expression without doing > any sanity checking. It does fall over if you try to apply it to stored rules: regression=# select pg_get_expr(ev_action, 0) from pg_rewrite; ERROR: unrecognized node type: 232 I'm not terribly excited about that, but maybe we should try to improve it while we're here. regards, tom lane