Re: Roadmap for FE/BE protocol redesign
От | Andrew Dunstan |
---|---|
Тема | Re: Roadmap for FE/BE protocol redesign |
Дата | |
Msg-id | 003d01c2e998$62ee2430$1a01000a@rduadunstan2 обсуждение исходный текст |
Ответ на | Re: Roadmap for FE/BE protocol redesign ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>) |
Список | pgsql-hackers |
Couldn't it be done optionally, so the clients that want the info pay the price and those that don't want it get the speed and lower bandwidth? Just a thought andrew ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> > "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes: > > Also doesn't the planner/executor already have all needed info available ? > > Not directly, and not necessarily in the form that the client would want > it in (eg, converting type OID to type name isn't free). I don't care > to load either the backend or the protocol down with the responsibility > for offering every piece of column data that a client could possibly > want as part of RowDescription. > > Besides, elsewhere in this thread we were hearing about how > RowDescription is already too much overhead for some people ;-) > > To my mind, the argument in favor of this feature is essentially that > it saves ODBC/JDBC from needing to duplicate the backend's SQL parser; > which is a legitimate concern. But that doesn't translate to saying > that we should push functionality out of the clients and into the > backend when it wouldn't be in the backend otherwise. That's just > moving code around on the basis of some rather-shaky arguments about > performance. And what happens when your client wants something > different from the exact functionality that was pushed to the backend? > You're back to square one. > > regards, tom lane
В списке pgsql-hackers по дате отправления: