Re: Roadmap for FE/BE protocol redesign - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re: Roadmap for FE/BE protocol redesign
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961F59@m0114.s-mxs.net
Whole thread Raw
In response to Roadmap for FE/BE protocol redesign  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: Roadmap for FE/BE protocol redesign
Next
From: Hannu Krosing
Date:
Subject: Re: Roadmap for FE/BE protocol redesign