Re: Roadmap for FE/BE protocol redesign
От | Barry Lind |
---|---|
Тема | Re: Roadmap for FE/BE protocol redesign |
Дата | |
Msg-id | 3E7122C8.1020902@xythos.com обсуждение исходный текст |
Ответ на | Re: Roadmap for FE/BE protocol redesign (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Barry Lind <blind@xythos.com> writes: > >>Tom Lane wrote: >> >>>See binary cursors ... > > >>Generally that is not an option. It either requires users to code to >>postgresql specific sql syntax, or requires the driver to do it >>magically for them. > > > Fair enough. I don't see anything much wrong with a GUC option that > says "send SELECT output in binary format". This is not really a > protocol issue since the ASCII and BINARY choices both exist at the > protocol level --- there is nothing in the protocol saying binary data > can only be returned by FETCH and not by SELECT. The main problem with > it in present releases is that binary data is architecture-dependent and > so encouraging its general use seems like a really bad idea. But if we > manage to get send/receive conversion routines in there, most of that > issue would go away. > That would be great. > >>The describe request is generally only >>done once even though you may do multiple fetchs (unlike todays protocol >>which includes the describe information on every fetch, even if you are >>fetching one row at a time). > > > I'm less than excited about changing that, because it breaks clients > that don't want to remember past RowDescriptions (libpq being the > front-line victim), and it guarantees loss-of-synchronization failures > anytime the client misassociates rowdescription with query. In exchange > for that, we get what exactly? Fetching one row at a time is > *guaranteed* to be inefficient. The correct response if that bothers > you is to fetch multiple rows at a time, not to make a less robust > protocol. I don't feel strongly either way on this one, but IIRC the SQL standard for cursors only specifies fetching one record at a time (at least that is how MSSQL and DB2 implement it). Thus portable code is likely to only fetch one record at a time. The current row description isn't too big, but with the changes being suggested it might become so. thanks, --Barry
В списке pgsql-hackers по дате отправления: