Re: Incorrect comment in get_partition_dispatch_recurse

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Incorrect comment in get_partition_dispatch_recurse
Дата
Msg-id f41b1ff5-732f-c46f-e4d7-3a2868b8bef2@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Incorrect comment in get_partition_dispatch_recurse  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: Incorrect comment in get_partition_dispatch_recurse  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
Hi David.

On 2018/05/14 13:57, David Rowley wrote:
> I noticed that a comment in get_partition_dispatch_recurse claims that:
> 
> "it contains the
> * leaf partition's position in the global list *leaf_part_oids minus 1"
> 
> The "minus 1" part is incorrect. It simply just stores the 0-based
> index of the item in the list.

Hmm, while I agree that simply calling it "0-based index" might be better
for readers, what's there now doesn't sound incorrect to me; in the
adjacent code:

        if (get_rel_relkind(partrelid) != RELKIND_PARTITIONED_TABLE)
        {
            *leaf_part_oids = lappend_oid(*leaf_part_oids, partrelid);
            pd->indexes[i] = list_length(*leaf_part_oids) - 1;
        }

If I call the value of list_length after adding an OID to the list the
OID's position in the list, we're storing into the indexes array exactly
what the existing comment says it is.  Now, literally describing the code
in the adjacent comment is not a great documentation style, so I'm open to
revising it like your patch does. :)

> I was going to fix it by removing just
> that part, but instead, I ended up rewriting the whole thing.
> 
> Patch attached.

Looks good to me, thanks.

Regards,
Amit



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: SPI/backend equivalent of extended-query Describe(statement)?
Следующее
От: Michael Paquier
Дата:
Сообщение: Temporary WAL segments files not cleaned up after an instance crash