Re: Roadmap for FE/BE protocol redesign

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Roadmap for FE/BE protocol redesign
Дата
Msg-id 7129.1047576747@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Roadmap for FE/BE protocol redesign  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Список pgsql-hackers
"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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: SQL99 ARRAY support proposal
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Roadmap for FE/BE protocol redesign