Robert Haas <robertmhaas@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
