Re: [HACKERS] libpq and SPI

Hi,

How did XML get into this discussion? What I was talking about was a
bug where, utility queries in a SPI procedure send command complete messages
between data type messages (T) and data value messages (D) which confuses
libpq.

Jerry

-----Original Message-----
From: frankpit(at)pop(dot)dn(dot)net <frankpit(at)pop(dot)dn(dot)net>
To: Gerald L. Gay <glgay(at)pass(dot)korea(dot)army(dot)mil>; pgsql-hackers(at)postgreSQL(dot)org
<pgsql-hackers(at)postgreSQL(dot)org>
Date: Sunday, February 28, 1999 1:54 AM
Subject: Re: [HACKERS] libpq and SPI

>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