Зависит от запросов в них.
Почти всегда лучше использовать inlinable SQL functions, а для чего-то "сложного" — plpgsql.

На самом деле думаю мы просто не понимаем друг друг друга. Что печально но решаемо. Я хотел бы понять в части размера данных массивы и результаты выборки select это сопоставимые сущности? В свою очередь я могу дать любые пояснения если это необходимо.

Да, решаемо. Если давать пояснения / отвечать на задаваемые вопросы, а не показывать что-то другое. ;)

> в части размера данных массивы и списки выборки select это сопоставимые сущности?

Вот о чём этот вопрос, например? Сколько будет занимать одно значение-массив (композитного типа) по сравнению с таблицей (того же типа) с теми же rows? Если да — то примерно столько же, обычно.
Но вот зачем это кому-то знать на практике в связи с тем, что Вы ранее описывали, я с трудом понимаю, если честно. ;)

Я вижу в функции единственную инструкцию RETURN QUERY SELECT.

plpgsql - выполняет роль glue language для SQL, но в функции из одной инструкции - "клей" не нужен.

Вероятнее всего plpgsql-версия будет НЕ хуже, чем просто SQL.

Впрочем, измеряйте все, не верьте утверждениям, но я не вижу обоснований для использования plpgsql в случаях, подобных Вашему

Массивы ест в sql?

есть

Обсуждения plpgsql vs SQL:

https://stackoverflow.com/q/24755468/1168212

Упоминается о кэшировании планов в plpgsql функциях и возможности inline в чистых SQL

Обратите внимание, что дискуссия была 7 лет назад

Об  inlining: https://wiki.postgresql.org/wiki/Inlining_of_SQL_functions

Если Вы обнаружите performance improvement при использовании plpgsql - это будет любопытно

Вообще просто читая топик я за две недели повысил произвольность в трое. Буду посмотреть

Спасибо

На пальцах, что меня беспокоит или вызывает сомнения таблица a к таблице b отношение один ко многим по таблице b я применяю функцию array_agg ко всему композитному типу таблицы. используя это решение я посрnоил view который собственно и тормозит (относительно), что бы избежать этих тормозов при ограниченном выборе я реалтзовал функцию упреждающей выборки по массиву id(уменьшающей количество агрегируемых данных до соответствующих условию) . И вот задумался а если массив будет большой я не упрусь в какие то системные ошибки. Собственно это все, пока не могу решить.

И я не могу в лоб переписать это на SQL CREATE OR REPLACE FUNCTION bpd.int_object_ext_prop_by_id_object_array(object_array bigint[])
RETURNS SETOF bpd.int_object_ext
LANGUAGE sql
STABLE PARALLEL SAFE
AS $function$
DECLARE
   --Описание: Функция упреждающей выборки свойств, используется для ограничения группировки свойств для расширенных представлений объектов
   --**************************************************************************
BEGIN
   SELECT op.id_object_carrier AS id,
   array_agg((op.*)::bpd.cobject_prop) AS property_list
   FROM bpd.vobject_prop op
   WHERE (op.id_object_carrier = ANY(object_array))
   GROUP BY op.id_object_carrier;
END;
$function$;

Коллеги, нужно сделать LEFT JOIN, отличный от тривиального ON (A.id = B.id).

Для примера пусть будут две таблицы с одним числовым полем каждая.

A.id
1
2
3
4
5
6

B.id
1
3
5

Нужно составить SELECT A.id, B.id FROM A LEFT JOIN B ..., чтобы в результате получить:

1, 1
2, 1
3, 3
4, 3
5, 5
6, NULL

Думаю, понятно. Для каждого id из таблицы A нужно найти соответствие по максимальному id из таблицы B, который не больше id из таблицы A. В сторону чего смотреть?

В сторону понимания того, что любой join - это, по сути, некое подмножество полного произведения двух таблиц, выбранное по предикату
ваша задача - составить предикат этого выбора

Ну, и какому условию ON соответствует данная выборка?  A.id ? B.id

А почему 6,null? По условию задачи 6,5 должно быть

ON(B.id FROM B WHERE B.id <= A.id ORDER BY B.id DESC LIMIT 1)

Да, действительно. Хотелось подчеркнуть, что для каждого id из А нужно что-то вывести, даже если не найдётся соответствия.

Нет, это не условие. В этом и проблема, составить предикат.

Речь идет об предварительном ограничении количества агрегируемых данных посредством передаваемого в функцию выборки массива идентификаторов, что позволяет не использовать полное представление на основе всех доступных строк. Завтра попробую ее таки перевести на SQL посмотрю на план и реальную выгоду это интересно.

Нет, речь идёт о том, что Вы ничего конкретного так и не показали! Где деньги планы, Зин? ;)

> что позволяет не использовать полное представление на основе всех доступных строк

И, что, в норме, должно работать и без подобных "плясок", но Вас это, я смотрю, не волнует. :(