Hi All,This question of an XML based frontend/backend protocol
has come up once before in the last few months on this list (or is this
the same thread even?) I am guessing that the underlying motivation is
that many, if not most, users of Postgres want to connect the database
to web-page user interfaces, and they would like the connection to be as
seamless as possible. From that point of view the proposal seems
reasonable, however I think that that point of view is limited, and that
tying the frontend/backend protocol to a specific frontend technology
would be a design mistake. Here are
two reasons:
1) Frontend technology is notoriously short lived. Postgres -- or at
least Ingres -- predates the internet, and since the beginning of
Postgres there have been at least three protocols for transmitting
formatted data over the internet (gopher, html, and now XML). I would
expect that the basic design of Postgres is good for at least another 10
years, could the same be said about the design of XML?
2) Although the majority of applications for Postgres are likely to use
web-based interfaces (or their successors), there are a significant
number of applications that do not. My use for Postgres is as an indexed
data store for large quantities of signal data, a typical front end for
me is a scripting language embedded in a numerical application. Fast and
simple are my primary requirements for a frontend/backend protocol.
More generally, I think that the strength of Postgres' design is that it
caters to a broad range of applications, and encourages experimentation
with the internals of the DBMS at a fundamental level. GIST, RTREEs, the
genetic optimizer, the myriad locking schemes, MVCC are all evidence of
this. If you need special support for XML, include it as a configurable
module, don't replace an existing generic solution with one that tailors
the system to a specific application.
Bernie Frankpitt