Re: Roadmap for FE/BE protocol redesign

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB SD
Тема Re: Roadmap for FE/BE protocol redesign
Дата
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961F59@m0114.s-mxs.net
обсуждение исходный текст
Ответ на Roadmap for FE/BE protocol redesign  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> > I'm still unclear on exactly what your needs are.  In the first place,
> > are you expecting to obtain data from arbitrary SELECT statements, or
> > only from statements of the form "SELECT * FROM single_table"?  You've
> > also been confusing as to whether you want transparency of views (ie,
> > does a select from a view return data about the view's nominal columns
> > or about the underlying base table columns?).  What about cases
> > involving aggregates or grouping --- there may be simple Vars in the
> > target list, but they can hardly be thought to represent
> updatable values.
>
> These questions can't possibly be unique to PG -- other database
> vendors must have answered these questions for their implementations
> of ODBC/JDBC too, or their databases would give ODBC and JDBC client
> authors the same kinds of trouble.
>
> So ... how have these questions been answered by other database
> vendors?

They return type info (RowDescription ('T') message) for "prepare", like Tom suggested.
See the more or less standardized ESQL/C data structure sqlda on what is needed
(label, type, length + precision, nullability, pointer to data (for binding host variables), ...). Note that this
structis used for both directions (so when inserting from host variables the interface knows what conversions need to
beapplied).  

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Zeugswetter Andreas SB SD"
Дата:
Сообщение: Re: Roadmap for FE/BE protocol redesign
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Roadmap for FE/BE protocol redesign