Re: [HACKERS] pg_class.relpartbound definition overly brittle

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: [HACKERS] pg_class.relpartbound definition overly brittle
Дата
Msg-id AE6B6FDC-2F9E-4BC6-A8C5-1E1C9F32EB01@gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_class.relpartbound definition overly brittle  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [HACKERS] pg_class.relpartbound definition overly brittle  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidaeis *still* broken)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] pg_class.relpartbound definition overly brittle