Ролг ХупинMelkijВременные таблицы (create temporary table) существуют только в пределах сессии (или даже только в пределах транзакции, если объявлены как ON COMMIT DROP). Поэтому параллельный вызов двух хранимок невозможен вообще никак.

Надо ли удалять - зависит от общего workflow. Мы же не знаем, зачем вам вообще понадобилась временная таблица.

Она нужна временно только в пределах функции.
То есть, если я создам ее

begin
create table xxx .... ON COMMIT DROP;
end;

то проблем не будет

проблем не будет
но не советую злоупотреблять временными таблицами без серьезного повода, очень дорогая штука для базы
(в том смысле что если хранимка вызывается 100 раз в секунду то не надо в ней временные таблицы использовать, это к проблемам с системными каталогами).

Ролг ХупинMaxim Bogukпропущено...


проблем не будет
но не советую злоупотреблять временными таблицами без серьезного повода, очень дорогая штука для базы
(в том смысле что если хранимка вызывается 100 раз в секунду то не надо в ней временные таблицы использовать, это к проблемам с системными каталогами).

эта функция не 100 раз в секунду, но надо будет подумать как избежать.
При этом я знаю, что в эту таблицу может быть вставлено не больше 1000 записей.

Вот, если бы было что-то типа таблиц-переменных как в SQL Server]

Если очень надо можно array of records всегда сделать да (и будет вам почти таблица-переменная).
Но вообще в readonly задачах временные таблицы не нужны в 99.9% случаев, а RW обычно не очень часто вызываются.

--
Maxim Boguk
www.postgresql-consulting.ru

Ролг ХупинMaxim Boguk Если очень надо можно array of records всегда сделать да (и будет вам почти таблица-переменная).
Но вообще в readonly задачах временные таблицы не нужны в 99.9% случаев, а RW обычно не очень часто вызываются.
www.postgresql-consulting.ru

Как с массивом работать?
С ним же нельзя работать как с таблицей, выборки делать и т.п.

Магическая функция unnest поможет с этой проблемой.
https://www.postgresql.org/docs/9.5/static/functions-array.html

--
Maxim Boguk
www.postgresql-consulting.ru

Ролг ХупинЕще вопрос:

когда могут быть полезны

ON COMMIT DELETE ROWS;
ON COMMIT PRESERVE ROWS;

?

Я так понимаю, что таблица живёт в клиентской сессии, а в ней можеть быть несколько транзакций, и таким образом можно использовать темп таблицу в разных транзакциях, функциях и т.д. и передавать данные (ON COMMIT PRESERVE ROWS)

А еще?

Еще при работе через pgbouncer бывает нужно когда временную таблицу создают в начале сессии средствами pgbouncer и далее она существует все это время с delete rows on commit и не надо в транзакциях и хранимках париться и ее создавать (она просто всегда уже создана с нужной структурой заранее).
Или даже без pgbouncer приложение при коннекте создает времянку и далее с ней работает не создавая ее заново на каждый чих.

Такие времянки сииильно дешевле для базы чем те что постоянно создаются и дропаются и их можно использовать с 1000tps блоках.

--
Maxim Boguk
www.postgresql-consulting.ru

g2099599Maxim BogukТакие времянки сииильно дешевле для базы чем те что постоянно создаются и дропаются и их можно использовать с 1000tps блоках.

Только вот TRUNCATE этих времянок не сильно дешев.

Сильно дешевле чем on commit drop с распуханием pg_catalog неконтролируемым.
PS: а почему вы считаете что truncate временных таблиц дорогой? Они же не в shared buffers живут и не требуют их сканирования при truncate.

--
Maxim Boguk
www.postgresql-consulting.ru