Re: Roadmap for FE/BE protocol redesign
От | Tom Lane |
---|---|
Тема | Re: Roadmap for FE/BE protocol redesign |
Дата | |
Msg-id | 27307.1047485980@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Roadmap for FE/BE protocol redesign (Barry Lind <blind@xythos.com>) |
Ответы |
Re: Roadmap for FE/BE protocol redesign
(Hannu Krosing <hannu@tm.ee>)
Re: Roadmap for FE/BE protocol redesign (Sean Chittenden <sean@chittenden.org>) Re: Roadmap for FE/BE protocol redesign (Greg Stark <gsstark@mit.edu>) Re: Roadmap for FE/BE protocol redesign (Barry Lind <blind@xythos.com>) Re: Roadmap for FE/BE protocol redesign (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
Barry Lind <blind@xythos.com> writes: > One addition I would personally like to see (it comes up in my apps > code) is the ability to detect wheather the server is big endian or > little endian. When using binary cursors this is necessary in order to > read int data. Actually, my hope is to eliminate that business entirely by standardizing the on-the-wire representation for binary data; note the reference to send/receive routines in the original message. For integer data this is simple enough: network byte order will be it. I'm not sure yet what to do about float data. > 2) Better support for domains. Currently the jdbc driver is broken with > regards to domains (although no one has reported this yet). The driver > will treat a datatype that is a domain as an unknown/unsupported > datatype. It would be great if the T response included the 'base' > datatype for a domain attribute so that the driver would know what > parsing routines to call to convert to/from the text representation the > backend expects. I'm unconvinced that we need do this in the protocol, as opposed to letting the client figure it out with metadata inquiries. If we should, I'd be inclined to just replace the typeid field with the base typeid, and not mention the domain to the frontend at all. Comments? > So I would request the ability of the client to set a max rows parameter > for query results. If a query were to return more than the max > number of rows, the client would be given a handle (essentially a cursor > name) that it could use to fetch additional sets of rows. How about simply erroring out if the query returns more than X rows? > 4) Protocol level support of PREPARE. In jdbc and most other > interfaces, there is support for parameterized SQL. If you want to take > advantage of the performance benefits of reusing parsed plans you have > to use the PREPARE SQL statement. This argument seems self-contradictory to me. There is no such benefit unless you're going to re-use the statement many times. Nor do I see how pushing PREPARE down to the protocol level will create any improvement in its performance. > So what I would like to see is the ability for the client to set a MAX > VALUE size parameter. The server would send up to this amount of data > for any column. If the value was longer than MAX VALUE, the server > would respond with a handle that the client could use to get the rest of > the value (in chunks of MAX VALUE) if it wanted to. I don't think I want to embed this in the protocol, either; especially not when we don't have even the beginnings of backend support for it. I think such a feature should be implemented and proven as callable functions first, and then we could think about pushing it down into the protocol. > 6) Better over the wire support for bytea. The current encoding of > binary data \000 results in a significant expansion in the size of data > transmitted. It would be nice if bytea data didn't result in 2 or 3 > times data expansion. AFAICS the only context where this could make sense is binary transmission of parameters for a previously-prepared statement. We do have all the pieces for that on the roadmap. regards, tom lane
В списке pgsql-hackers по дате отправления: