> On May 31, 2017, at 2:49 PM, Alvaro Herrera <alvhe...@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
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 :constbyval true :constisnull false
: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 :constbyval true
:constisnull false :location -1 :constvalue 2 [ 0 0 0 0 0 0 0 0 ]})
:lowerdatums <> :upperdatums <> :location 73} | f | f
(1 row)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
