Получить 3 набора записей из функции

С клиента (на delphi) требуется вызвать функцию сервера, которая возвратит 3 множества записей, разумеется с разной структурой. *Важное уточнение: от обмена клиент-сервер требуется максимальное быстродействие, при условии что часть клиентов подключена через медленное соединение.

В PL/pgSQL пока разбираюсь не настолько, чтобы сообразить, возможно ли вернуть их через out-параметры, да и непонятно, как с клиента-то их прочитать. Скорее всего, так нельзя...

Значит, придётся возвратить только один набор, а остальные получить отдельными вызовами. Тогда сервер должен временно сохранить эти наборы до последующих вызовов с клиента. Видимо, следует задействовать временные таблицы? Или лучше, учитывая (*), упаковать эти наборы в bytea - наборы и передать сразу..?

Какая бест-практик в моём случае?

_avz

С клиента (на delphi) требуется вызвать функцию сервера, которая возвратит 3 множества записей, разумеется с разной структурой. *Важное уточнение: от обмена клиент-сервер требуется максимальное быстродействие, при условии что часть клиентов подключена через медленное соединение. В PL/pgSQL пока разбираюсь не настолько, чтобы сообразить, возможно ли вернуть их через out-параметры, да и непонятно, как с клиента-то их прочитать. Скорее всего, так нельзя... Значит, придётся возвратить только один набор, а остальные получить отдельными вызовами. Тогда сервер должен временно сохранить эти наборы до последующих вызовов с клиента. Видимо, следует задействовать временные таблицы? Или лучше, учитывая (*), упаковать эти наборы в bytea - наборы и передать сразу..? Какая бест-практик в моём случае?

варианта три
1)вернуть 1 большой json ответ
2)вернуть 3 массива составных типов (тот же json просто сериализация другая)
3)вернуть 3 курсора и клиентом затем из них вычитать 3мя дополнительными ззапросами

PS: через out параметры вы задачу не решите. через временные таблицы не советую - очень дорогое решение.

_avz
С клиента (на delphi) требуется вызвать функцию сервера, которая возвратит 3 множества записей, разумеется с разной структурой.

Этого не может быть, потому что этого не может быть никогда. :-)
В plpg/sql типизация сильная.
Можно конечно извратиться, чтобы одна функция возвращала 3 разных типа, но это будет полный изврат. Так лучше не делать

_avz
В PL/pgSQL пока разбираюсь не настолько, чтобы сообразить, возможно ли вернуть их через out-параметры, да и непонятно, как с клиента-то их прочитать. Скорее всего, так нельзя...

Считайте что нельзя!
Так будет лучше, в т.ч. и вам.

_avz
Значит, придётся возвратить только один набор, а остальные получить отдельными вызовами. Тогда сервер должен временно сохранить эти наборы до последующих вызовов с клиента. Видимо, следует задействовать временные таблицы? Или лучше, учитывая (*), упаковать эти наборы в bytea - наборы и передать сразу..? Какая бест-практик в моём случае?

Бест-практик в вашем случае выбросить глупости из головы.
Делать нужно правильно!
Т.е. если вам нужно три разных результата, то нужно делать три разных запроса.

_avz,

много букв, мало деталей сути задачи, характеристик и связей результатов.

_avz

С клиента (на delphi) требуется вызвать функцию сервера, которая возвратит 3 множества записей, разумеется с разной структурой. *Важное уточнение: от обмена клиент-сервер требуется максимальное быстродействие, при условии что часть клиентов подключена через медленное соединение. В PL/pgSQL пока разбираюсь не настолько, чтобы сообразить, возможно ли вернуть их через out-параметры, да и непонятно, как с клиента-то их прочитать. Скорее всего, так нельзя... Значит, придётся возвратить только один набор, а остальные получить отдельными вызовами. Тогда сервер должен временно сохранить эти наборы до последующих вызовов с клиента. Видимо, следует задействовать временные таблицы? Или лучше, учитывая (*), упаковать эти наборы в bytea - наборы и передать сразу..? Какая бест-практик в моём случае?

а NextRecordset (или что-то около) в ADO отключили ?

есть стандратный бэд паттерн -- открыть три курсора и держать транзакцию открытой с клиента -- распространён у аров-калоедов. но это особенности ара-кала, как вструмента, им диктуют. жалко их

Maxim Boguk
варианта три 1)вернуть 1 большой json ответ

для моего клиента не самое удобное (компоненты pgDAC не поддерживают)

2)вернуть 3 массива составных типов (тот же json просто сериализация другая)

Спасибо за идею, посмотрю как с этим в pgDAC, но думаю что придётся вручную разбирать.

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

спасибо, поизучаю такую возможность

через временные таблицы не советую - очень дорогое решение.

В том смысле, что быстродействие будет не очень? Например, если создать эти темп. таблицы один раз за сессию, а в каждом вызове функции их перезаполнять?

mad_nazgul
Делать нужно правильно! Т.е. если вам нужно три разных результата, то нужно делать три разных запроса.

Вообще - да, только тогда получится что самый тяжёлый запрос будет выполнен трижды, в то время как в моём случае возможно подобрать все нужные данные, исполнив его единожды.

?Ы
а NextRecordset (или что-то около) в ADO отключили ?

на клиенте используется библиотека pgDAC.

запись массивов записей
_avz, много букв, мало деталей сути задачи, характеристик и связей результатов.

Деталями задачи грузить не хотелось бы, вопрос больше про возможности, имеющиеся у субд.

_avz
mad_nazgul Делать нужно правильно! Т.е. если вам нужно три разных результата, то нужно делать три разных запроса. Вообще - да, только тогда получится что самый тяжёлый запрос будет выполнен трижды, в то время как в моём случае возможно подобрать все нужные данные, исполнив его единожды.

Так сделайте один запрос в котором возвратиться все что надо. :-)
Потом раскидайте по нужным вам спискам.