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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
