BUG #14953: pg_blocking_pids / array_length inconsistency

Поиск
Список
Период
Сортировка
От steven.winfield@cantabcapital.com
Тема BUG #14953: pg_blocking_pids / array_length inconsistency
Дата
Msg-id 20171207144028.21691.76008@wrigleys.postgresql.org
обсуждение исходный текст
Ответы Re: BUG #14953: pg_blocking_pids / array_length inconsistency  (Marko Tiikkaja <marko@joh.to>)
Re: BUG #14953: pg_blocking_pids / array_length inconsistency  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
The following bug has been logged on the website:

Bug reference:      14953
Logged by:          Steven Winfield
Email address:      steven.winfield@cantabcapital.com
PostgreSQL version: 10.0
Operating system:   Linux
Description:

It seems as though pg_blocking_pids() can return a zero-length,
one-dimensional array whereas users can only create NULL-length,
zero-dimensional arrays (even though the type suggests it is one
dimensional: 'integer[]')

test=# SELECT pg_blocking_pids(pg_backend_pid()),
array_length(pg_blocking_pids(pg_backend_pid()), 1), '{}'::integer[],
array_length('{}'::integer[], 1);
 pg_blocking_pids | array_length | int4 | array_length
------------------+--------------+------+--------------
 {}               |            0 | {}   |
(1 row)

This means that, for example, the code to check for an empty array of PIDs
must be special-cased.

For what it's worth, I think having array_length('{}'::integer[], 1) = 0 is
far more sensible, and 
making differently-dimensioned empty arrays compare equal (as mentioned
previously[1]) is quite confusing.


[1]
https://www.postgresql.org/message-id/tencent_5D502954744B7F744ED6F34E%40qq.com


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

Предыдущее
От: "Raghavendra Rao Jsv -X (rjsv - SCARLET WIRELESS INDIA PRIVATE LIMITEDat Cisco)"
Дата:
Сообщение: missing chunk number 0 for toast value 1086251 in pg_toast_2619
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: BUG #14953: pg_blocking_pids / array_length inconsistency