On 2017-05-31 15:06:06 -0700, Mark Dilger wrote:
> That's cold comfort, given that most users will be looking at the pg_class
> table and not writing C code that compares Node objects. I wrote a bit of
> regression test logic that checks, and sure enough the relpartbound field
> shows up as unequal:
>
relpartbound --------------------------------------------
> SELECT a.relpartbound, b.relpartbound, a.relpartbound = b.relpartbound, a.relpartbound::text = b.relpartbound::text
> FROM pg_class a, pg_class b
> WHERE a.relname = 'acct_partitioned_1'
> AND b.relname = 'acct_partitioned_2';
>
relpartbound
|
relpartbound
| ?column? | ?column?
>
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------
> {PARTITIONBOUNDSPEC :strategy l :listdatums ({CONST :consttype 23000 :consttypmod -1 :constcollid 0 :constlen 2
:constbyvaltrue :constisnull false :location -1 :constvalue 2 [ 0 0 0 0 0 0 0 0 ]}) :lowerdatums <> :upperdatums <>
:location82} | {PARTITIONBOUNDSPEC :strategy l :listdatums ({CONST :consttype 23000 :consttypmod -1 :constcollid 0
:constlen2 :constbyval true :constisnull false :location -1 :constvalue 2 [ 0 0 0 0 0 0 0 0 ]}) :lowerdatums <>
:upperdatums<> :location 73} | f | f
> (1 row)
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)
- Andres