Re: [HACKERS] pg_class.relpartbound definition overly brittle - Mailing list pgsql-hackers
From | Mark Dilger |
---|---|
Subject | Re: [HACKERS] pg_class.relpartbound definition overly brittle |
Date | |
Msg-id | AE6B6FDC-2F9E-4BC6-A8C5-1E1C9F32EB01@gmail.com Whole thread Raw |
In response to | Re: [HACKERS] pg_class.relpartbound definition overly brittle (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Responses |
Re: [HACKERS] pg_class.relpartbound definition overly brittle
(Andres Freund <andres@anarazel.de>)
|
List | pgsql-hackers |
> On May 31, 2017, at 2:49 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > Mark Dilger wrote: >> Hackers, >> >> recent changes have introduced the :location field to the partboundspec >> in pg_catalog.pg_class. This means that if two identical tables with >> identical partitioning scheme are created, but one is done before a change >> to gram.y, and the other after a change to gram.y, the relpartbound fields >> for those two tables could show up as different. > > Actually, if you look at equalfuncs.c, you'll note that locations are > not really compared: > > /* Compare a parse location field (this is a no-op, per note above) */ > #define COMPARE_LOCATION_FIELD(fldname) \ > ((void) 0) > > where the referenced note is: > > * NOTE: it is intentional that parse location fields (in nodes that have > * one) are not compared. This is because we want, for example, a variable > * "x" to be considered equal() to another reference to "x" in the query. 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 FROMpg_class a, pg_class b WHERE a.relname = 'acct_partitioned_1' AND b.relname = 'acct_partitioned_2'; relpartbound | relpartbound | ?column?| ?column? ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------{PARTITIONBOUNDSPEC :strategyl :listdatums ({CONST :consttype 23000 :consttypmod -1 :constcollid 0 :constlen 2 :constbyval true :constisnullfalse :location -1 :constvalue 2 [ 0 0 0 0 0 0 0 0 ]}) :lowerdatums <> :upperdatums <> :location 82} | {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 <> :location73} | f | f (1 row)
pgsql-hackers by date: