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
|
| 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: