Re: PERSISTANT PREPARE (another point of view)

Поиск
Список
Период
Сортировка
От Milan Oparnica
Тема Re: PERSISTANT PREPARE (another point of view)
Дата
Msg-id g5ln0n$25mi$1@news.hub.org
обсуждение исходный текст
Ответ на Re: PERSISTANT PREPARE (another point of view)  (Milan Oparnica <milan.opa@gmail.com>)
Ответы Re: PERSISTANT PREPARE (another point of view)  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Re: PERSISTANT PREPARE (another point of view)  (Richard Huxton <dev@archonet.com>)
Список pgsql-sql
Milan Oparnica wrote:
> 
> It's simply to complicated to return recordsets through server-side 
> stored procedures. They are obviously designed to do complex data 
> manipulation, returning few output variables informing the caller about 
> final results. Returning records through sets of user-defined-types is 
> memory and performance waste (please see my previous post as reply to 
> Steve for more details). Plus it's hard to maintain and make 
> improvements to such a system. I hate to see 800 user types made for 
> every query we made as stored procedure.

Is this topic completely out of scope in Postgre ?
If I'm missing something too obvious or too important, please let me 
know what.

I run over and over through internet and Postgre documentation and still 
found nothing.

Is there a better place to communicate with Postgre developers ?

Sincerely,

Milan Oparnica


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

Предыдущее
От: Volkan YAZICI
Дата:
Сообщение: pg_advisory_lock(bigint) vs. LOCK TABLE
Следующее
От: "Pavel Stehule"
Дата:
Сообщение: Re: PERSISTANT PREPARE (another point of view)