Christof Petig wrote:
> Neil Conway wrote:
>
>> (6) Protocol-level support for prepared queries, in order to
>> bypass the parser (and maybe be more compatible with the
>> implementation of prepared queries in other databases).
>
>
> Let me add
> (6b) Protocol level support for query parameters. This would actually
> make (6) more powerful and speed up non prepared (but similar)
> queries via the query cache (which is already there IIRC).
> [I talk about <statement> USING :var ... ]
>
> (n) Platform independant binary representation of parameters and
> results (like in CORBA). This can _really_ speed up
> communication with compiled programs if you take the time to
> implement it. This was previously planned for a future
> CORBA fe/be protocol, but this does not seem to come any time
> soon.
After one night's sleep I think that perhaps a CORBA based protocol
might be less work (but I have no idea about a decent authentification
schema, I'd tend to reuse the already authentificated stream). A
corbaized query-only interface might easily cover these issues and be
less work than a full corba backend access. JDBC (I don't know much
about it) might give a reasonable interface design (perhaps combined
with a libpq[++|xx] like interface if there's benefit to it).
> (n+1) Optional additional Result qualifiers. E.g. dynamic embedded
> sql has a
> flag to indicate that this column is a key. Previously it was
> impossible to set this flag to a meaningful value. Also
> the standard has additional statistical information about the
> size of the column etc. If it's unclear what I'm talking about
> I will look up the exact location in the standard (it's embedded
> sql, dynamic sql, get descriptor)
This does not need an implementation soon. But the new protocol should
allow future things like this.
All these proposals are motivated by (future) ecpg [C/C++] needs. So
IMHO the ODBC, JDBC, libpqxx people might be interested in many of these
issues, too. We definitely should make sure to have asked them.
Yours Christof
