Bruce Momjian wrote:
>
> Current FE/BE protocol seems pretty optimized to me, but you should know
> the best. Seems like a waste to try and get it to match some standard,
> expecially if we can just create a module to do it on top of the
> existing protocol.
>
It may be pretty optimized, but in its current implementation it seems
it has just evolved into the current shape, and not engineered to be
a efficient and consistent interface.
The way it has become as it is seems to be grown from the need to
talk to the backend directly using telnet.
Otherways the protocol is a bitch to implement (comared for example to
X)
as it is very inconsistent in ways lengths are specified, and also lacks
many features needed from standard SQL CLI spec, like prepared
statements and such; (Implementing prepared statements on top of
current protocol would need quite a lot of gum, wire and black tape)
The binary protocol is very much lacking (read unimplemented) - there
are places for network input/output functions in the pg_type table,
(I guess typsend/typreceive were ment to be used in binary mode
cursors) but they are not used (they are always the same as
typoutput/typsend)
having really standard network independent binary representations
(using typsend/typreceive) for all types would be one thing to ease
implementation of higher-level client libraries (ODBC,JDBC,...)
Currently everything goes through ascii as it is the only
architecture and network independent way.
I have been entertaining an idea to design a new protocol based on
X Window protocol, but probably the CORBA one (GIOP ?) is more advanced,
at least in fields like security, marshalling of new user-defined
datatypes and others. It does probably not suffer from arbitrary 8k
limits in unexpected places ;)
So, as we will need a new FE<->BE protocol anyway, why not try to
use CORBA.
-------------
Hannu Krosing