Re: Roadmap for FE/BE protocol redesign

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(at)sss(dot)pgh(dot)pa(dot)us>

> "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)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