Christof Petig wrote:
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).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.
(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)
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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
