Re: [HACKERS] Re: retrieving varchar size
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: retrieving varchar size |
Дата | |
Msg-id | 4148.893687967@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: retrieving varchar size (Michael Hirohama <kamesan@ricochet.net>) |
Ответы |
Re: [HACKERS] Re: retrieving varchar size
|
Список | pgsql-hackers |
Michael Hirohama <kamesan@ricochet.net> writes: > The historical reason why the POSTGRES backend is required to send multiple > result sets is to support cursors on queries involving type inheritance and > anonymous target lists. > begin > declare c cursor for > select e.oid, e.* from EMP* e > fetch 10 in c > ... > To handle the command sequence above, frontend applications would need to > be provided with a new result descriptor when the "fetch 10 in c" crosses a > result set boundary. Hmm. I noted the place in libpq where it fails if multiple 'T' (tuple descriptor) messages arrive during a query retrieval. But the comments made it sound like the condition shouldn't occur. Does what you describe actually work in the current backend? The problem on the libpq side is basically that the PGresult structure is not able to represent more than one tuple descriptor. AFAICS, we can't tamper with that without breaking all existing applications. However, if we make the changes being discussed in this thread then it would be a simple matter to return a *series* of PGresult structures for this sort of query. Whether an application is capable of handling that is another story, but at least the data could be passed through. regards, tom lane
В списке pgsql-hackers по дате отправления: