Re: Roadmap for FE/BE protocol redesign

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
Cc: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>, pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Roadmap for FE/BE protocol redesign
Date: 2003-03-13 17:32:27
Message-ID: 7129.1047576747@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-03-13 17:41:41 Re: Roadmap for FE/BE protocol redesign
Previous Message Tom Lane 2003-03-13 17:12:46 Re: SQL99 ARRAY support proposal