PostgreSQL unnest () з номером елемента


90

Коли у мене є стовпець з відокремленими значеннями, я можу використовувати unnest()функцію:

myTable
id | elements
---+------------
1  |ab,cd,efg,hi
2  |jk,lm,no,pq
3  |rstuv,wxyz

select id, unnest(string_to_array(elements, ',')) AS elem
from myTable

id | elem
---+-----
1  | ab
1  | cd
1  | efg
1  | hi
2  | jk
...

Як я можу включити номери елементів? Тобто:

id | elem | nr
---+------+---
1  | ab   | 1
1  | cd   | 2
1  | efg  | 3
1  | hi   | 4
2  | jk   | 1
...

Я хочу вихідне положення кожного елемента у вихідному рядку. Я спробував з віконними функціями ( row_number(), і rank()т.д.) , але я завжди отримую 1. Може тому, що вони знаходяться в одному рядку вихідної таблиці?

Я знаю, що це поганий дизайн столу. Це не моє, я просто намагаюся це виправити.

Відповіді:


184

Postgres 9.4 або пізнішої версії

Використання WITH ORDINALITYдля функцій, що повертають набір:

Коли функція в FROMреченні суфіксується WITH ORDINALITY, bigintдо виводу додається стовпець, який починається з 1 і збільшується на 1 для кожного рядка виводу функції. Це найбільш корисно у випадку встановлених функцій, що повертають, таких як unnest().

У поєднанні з LATERALфункцією в pg 9.3+ і відповідно до цього потоку на pgsql-хакерах , наведений вище запит тепер можна записати як:

SELECT t.id, a.elem, a.nr
FROM   tbl AS t
LEFT   JOIN LATERAL unnest(string_to_array(t.elements, ','))
                    WITH ORDINALITY AS a(elem, nr) ON TRUE;

LEFT JOIN ... ON TRUEзберігає всі рядки в лівій таблиці, навіть якщо вираз таблиці праворуч не повертає жодного рядка. Якщо це не викликає занепокоєння, ви можете скористатися цією еквівалентною, менш детальною формою з неявним CROSS JOIN LATERAL:

SELECT t.id, a.elem, a.nr
FROM   tbl t, unnest(string_to_array(t.elements, ',')) WITH ORDINALITY a(elem, nr);

Або простіше, якщо базується на фактичному масиві ( arrє стовпцем масиву):

SELECT t.id, a.elem, a.nr
FROM   tbl t, unnest(t.arr) WITH ORDINALITY a(elem, nr);

Або навіть, з мінімальним синтаксисом:

SELECT id, a, ordinality
FROM   tbl, unnest(arr) WITH ORDINALITY a;

a- це автоматично псевдонім таблиці та стовпця. Ім'я за замовчуванням для доданого стовпця порядку - ordinality. Але краще (безпечніше, чистіше) додавати явні псевдоніми стовпців і стовпці, що відповідають таблиці.

Postgres 8.4 - 9.3

Коли row_number() OVER (PARTITION BY id ORDER BY elem)ви отримуєте числа відповідно до порядку сортування, а не порядкового номера вихідної порядкової позиції в рядку.

Ви можете просто пропустити ORDER BY:

SELECT *, row_number() OVER (PARTITION by id) AS nr
FROM  (SELECT id, regexp_split_to_table(elements, ',') AS elem FROM tbl) t;

Хоча це зазвичай працює, і я ніколи не бачив, щоб він пропадав у простих запитах, PostgreSQL не стверджує нічого щодо порядку рядків без ORDER BY. Це трапляється працювати завдяки деталям реалізації.

Щоб гарантувати порядкові номери елементів у розділеному пробілом рядку :

SELECT id, arr[nr] AS elem, nr
FROM  (
   SELECT *, generate_subscripts(arr, 1) AS nr
   FROM  (SELECT id, string_to_array(elements, ' ') AS arr FROM tbl) t
   ) sub;

Або простіше, якщо базується на фактичному масиві :

SELECT id, arr[nr] AS elem, nr
FROM  (SELECT *, generate_subscripts(arr, 1) AS nr FROM tbl) t;

Відповідна відповідь на dba.SE:

Postgres 8,1 - 8,4

Жодна з цих функцій не доступні, але: RETURNS TABLE, generate_subscripts(), unnest(), array_length(). Але це працює:

CREATE FUNCTION f_unnest_ord(anyarray, OUT val anyelement, OUT ordinality integer)
  RETURNS SETOF record
  LANGUAGE sql IMMUTABLE AS
'SELECT $1[i], i - array_lower($1,1) + 1
 FROM   generate_series(array_lower($1,1), array_upper($1,1)) i';

Зауважте, зокрема, що індекс масиву може відрізнятися від порядкових позицій елементів. Розглянемо цю демонстрацію з розширеною функцією :

CREATE FUNCTION f_unnest_ord_idx(anyarray, OUT val anyelement, OUT ordinality int, OUT idx int)
  RETURNS SETOF record
  LANGUAGE sql IMMUTABLE AS
'SELECT $1[i], i - array_lower($1,1) + 1, i
 FROM   generate_series(array_lower($1,1), array_upper($1,1)) i';

SELECT id, arr, (rec).*
FROM  (
   SELECT *, f_unnest_ord_idx(arr) AS rec
   FROM  (VALUES (1, '{a,b,c}'::text[])  --  short for: '[1:3]={a,b,c}'
               , (2, '[5:7]={a,b,c}')
               , (3, '[-9:-7]={a,b,c}')
      ) t(id, arr)
   ) sub;

 id |       arr       | val | ordinality | idx
----+-----------------+-----+------------+-----
  1 | {a,b,c}         | a   |          1 |   1
  1 | {a,b,c}         | b   |          2 |   2
  1 | {a,b,c}         | c   |          3 |   3
  2 | [5:7]={a,b,c}   | a   |          1 |   5
  2 | [5:7]={a,b,c}   | b   |          2 |   6
  2 | [5:7]={a,b,c}   | c   |          3 |   7
  3 | [-9:-7]={a,b,c} | a   |          1 |  -9
  3 | [-9:-7]={a,b,c} | b   |          2 |  -8
  3 | [-9:-7]={a,b,c} | c   |          3 |  -7

Порівняйте:


10
Ця відповідь є однією з найбільш вичерпних відповідей у ​​SO щодо PostgreSQL. Дякую Ервін.
Александрос

Чи можемо ми адаптувати функцію unnest2 нижче до реального повернення таблиці (не підроблених рядків), у нових версіях pg?
Пітер Краус

@ erwin-brandtetter, не могли б Ви детальніше пояснити, чому / якщо WITH ORDINALITYце переважно generate_subscripts()? Мені здається, generate_subscripts()це краще, оскільки воно показує фактичне розташування елемента в масиві. Це корисно, наприклад, при оновленні масиву ... чи слід використовувати WITH ORDINALITYзамість нього?
losthorse

1
@losthorse: Я б окреслив це так: WITH ORDINALITYце загальне рішення для отримання номерів рядків для будь-якого набору, що повертає функцію в запиті SQL. Це найшвидший, надійний спосіб, і він також прекрасно працює для одновимірних масивів на основі 1 (за замовчуванням для масивів Postgres, розгляньте це ). Якщо ви працюєте з будь-якими іншими типами масивів (більшість людей цього не роблять), і вам насправді потрібно зберегти / працювати з оригінальними індексами, generate_subscripts()це шлях. Але unnest()для початку все згладжується ...
Ервін Брандштеттер,

1
@ z0r_ Посібник: Table functions appearing in FROM can also be preceded by the key word LATERAL, but for functions the key word is optional; the function's arguments can contain references to columns provided by preceding FROM items in any case.
Ервін Брандштеттер

9

Спробуйте:

select v.*, row_number() over (partition by id order by elem) rn from
(select
    id,
    unnest(string_to_array(elements, ',')) AS elem
 from myTable) v

6

Використовуйте функції генерації індексу .
http://www.postgresql.org/docs/current/static/functions-srf.html#FUNCTIONS-SRF-SUBSCRIPTS

Наприклад:

SELECT 
  id
  , elements[i] AS elem
  , i AS nr
FROM
  ( SELECT 
      id
      , elements
      , generate_subscripts(elements, 1) AS i
    FROM
      ( SELECT
          id
          , string_to_array(elements, ',') AS elements
        FROM
          myTable
      ) AS foo
  ) bar
;

Простіше:

SELECT
  id
  , unnest(elements) AS elem
  , generate_subscripts(elements, 1) AS nr
FROM
  ( SELECT
      id
      , string_to_array(elements, ',') AS elements
    FROM
      myTable
  ) AS foo
;

3

Якщо порядок елементів не важливий, ви можете

select 
  id, elem, row_number() over (partition by id) as nr
from (
  select
      id,
      unnest(string_to_array(elements, ',')) AS elem
  from myTable
) a

0

unnest2() як вправу

Старіші версії до pg v8.4 потребують визначеного користувачем unnest(). Ми можемо адаптувати цю стару функцію для повернення елементів з індексом:

CREATE FUNCTION unnest2(anyarray)
  RETURNS setof record  AS
$BODY$
  SELECT $1[i], i
  FROM   generate_series(array_lower($1,1),
                         array_upper($1,1)) i;
$BODY$ LANGUAGE sql IMMUTABLE;

2
Це не спрацювало б до pg v8.4, оскільки цього RETURNS TABLEще немає. Я додав главу до своєї відповіді, де обговорювалось рішення.
Ервін Брандштеттер

1
@ErwinBrandstetter, ваші відповіді дуже дидактичні, і ви шліфуєте текст 4-річної давності (!) ... Ви пишете книгу PostgreSQL, використовуючи ваші тексти SO? :-)
Пітер Краус

Привіт усім, це Wiki, ви можете редагувати (!) ... Але добре, я виправив setof record.
Пітер Краус
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.