On 2017-05-31 15:38:58 -0700, Mark Dilger wrote:
> > Normal users aren't going to make sense of node trees in the first
> > place. You should use pg_get_expr for it:
> > postgres[3008][1]=# SELECT pg_get_expr(relpartbound, oid) FROM pg_class WHERE relpartbound IS NOT NULL;
> > ┌──────────────────────┐
> > │ pg_get_expr │
> > ├──────────────────────┤
> > │ FOR VALUES IN (1, 2) │
> > └──────────────────────┘
> > (1 row)
>
> I concede that mitigates the problem somewhat, though I still think a user may look
> at pg_class, see there is a column that appears to show the partition boundaries,
> and then decide to check whether two tables have the same partition boundaries
> by comparing those fields, without passing them first through pg_get_expr(), a
> function they may never have heard of.
>
> To me, it seems odd to immortalize a SQL parsing field in the catalog definition of
> the relation, but perhaps that's just my peculiar sensibilities. If the community is more
> on your side, I'm not going to argue it.
Given that various other node trees stored in the catalog also have
location fields, about which I recall no complaints, I don't think this
is a significant issue. Nor something that I think makes sense to solve
in isolation, without tackling all stored expressions.
- Andres