2 patches

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Two small patches are attached, both against current CVS:

1. Some security, since we now have vsnprintf, I remade an old patch
with some extra ugly sprintfs fixed. More work in this area is
needed still. (pg.diff.gz)

Applied to CURRENT tree.

2. Is a experimental patch to libpq and psql to make XML output an
alternative to to traditional and HTML3 output. (pg2.diff.gz)

Not applied, as you suggested.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Yesterday I posted a quick patch to make libpq able to output
some home brew (but valid) XML as an alternative to normal and HTML3
output.

The propose was to start a discussion how we could use XML in PgSQL.

I mentioned in my previous mail I would like to use XML in the FE/BE
protocol. That would leav us with 3 protocols, the current one, CORBA
and XML. But I would argue that CORBA and XML are more related since
they are both object based. In the long run the current protocol could
be dropped.

Pro and cons of using XML:
+ Object-oriented (fits well with our ORDBMS project)
+ Clear text (easily debugged)
+ Easliy display in next generation network tools (even without
  middleware in some cases)
+ In coupled to DOM, easily manipulatable both on server and/or client
side.
- In theory a little slower than an binary protocol.

XML is a buzzword, but it has enormous potential,
and it is not foreign to the pgsql community since
we are already using the father of XML (SGML) for
the docs.

Suggestion:
CORBA and XML should replace current FE/BE-protocol for v. 7.0
Comments?

best regards and a wishes for a good 1999,
--
-----------------
G�ran Thyni
This is Penguin Country. On a quiet night you can hear Windows NT
reboot!

XML is a buzzword, but it has enormous potential,
and it is not foreign to the pgsql community since
we are already using the father of XML (SGML) for
the docs.

Suggestion:
CORBA and XML should replace current FE/BE-protocol for v. 7.0
Comments?

I vote against it. Maybe nice to have as an extra, but the base
protocol seems to work well, and is fast.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:

XML is a buzzword, but it has enormous potential,
and it is not foreign to the pgsql community since
we are already using the father of XML (SGML) for
the docs.

Suggestion:
CORBA and XML should replace current FE/BE-protocol for v. 7.0
Comments?

I vote against it. Maybe nice to have as an extra, but the base
protocol seems to work well, and is fast.

You are right,
let me rephrase myself:
- the "base protocol" might become obsolite if and when we have
a better object base alternative (CORBA and/or XML).
- this might be the case for v. 7.0 or later.

This is an idea for a game plan:
1. Make a proxy server
2. Integrate it in postmaster when stable (code-wise and protocol-wise)
3. Add closer integration with DB-objects

This game plan would perhaps work to get CORBA of the ground too,
there might even be sensible to make a common CORBA/XML-proxy.

I will look in to this, but will be working out of town for 2 months
(mainly feb-mars) so I will not promise anything for 6.5.

Any help or input (right now comment on the DTD etc) welcome.

regards,
--
-----------------
G�ran Thyni
This is Penguin Country. On a quiet night you can hear Windows NT
reboot!

On Sat, 2 Jan 1999, Goran Thyni wrote:

Bruce Momjian wrote:

XML is a buzzword, but it has enormous potential,
and it is not foreign to the pgsql community since
we are already using the father of XML (SGML) for
the docs.

Suggestion:
CORBA and XML should replace current FE/BE-protocol for v. 7.0
Comments?

I vote against it. Maybe nice to have as an extra, but the base
protocol seems to work well, and is fast.

You are right,
let me rephrase myself:
- the "base protocol" might become obsolite if and when we have
a better object base alternative (CORBA and/or XML).
- this might be the case for v. 7.0 or later.

Okay, we have to sides to the coin here...Bruce, who feels that our
current protocol is both good and fast, and you, who wants to replace it
:)

My question is simple...what benefit is gained by replacing current
protocol? And, what cons?

Replacing something is great, if there is a reason...what is that reason
and how does that improve us?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

The Hermit Hacker wrote:

On Sat, 2 Jan 1999, Goran Thyni wrote:

Bruce Momjian wrote:

I vote against it. Maybe nice to have as an extra, but the base
protocol seems to work well, and is fast.

You are right,
let me rephrase myself:
- the "base protocol" might become obsolite if and when we have
a better object base alternative (CORBA and/or XML).
- this might be the case for v. 7.0 or later.

Okay, we have to sides to the coin here...Bruce, who feels that our
current protocol is both good and fast, and you, who wants to replace it
:)

My question is simple...what benefit is gained by replacing current
protocol? And, what cons?

Replacing something is great, if there is a reason...what is that reason
and how does that improve us?

Marc,

The pros, IMHO:
* XML interfaces better to the object model of pgsql itself
* XML interfaces better to XML-viewer, like next generation of
web browsers.

With a little imagination we can at some point in the future forget
about making clients for the databases, just point your webbrowser
at the serverport a make both SELECTs (displays) and INSERT/UPDATE
(forms) with a few lines of javascript.

The con:
* We have a good stable protocol but a little simplistic.
Anything new is not as good until it has matured.

Thus I not suggesting replacing it until we have something
better, sound resonable?

mvh,
--
-----------------
G�ran Thyni
This is Penguin Country. On a quiet night you can hear Windows NT
reboot!

The pros, IMHO:
* XML interfaces better to the object model of pgsql itself
* XML interfaces better to XML-viewer, like next generation of
web browsers.

With a little imagination we can at some point in the future forget
about making clients for the databases, just point your webbrowser
at the serverport a make both SELECTs (displays) and INSERT/UPDATE
(forms) with a few lines of javascript.

The con:
* We have a good stable protocol but a little simplistic.
Anything new is not as good until it has matured.

Thus I not suggesting replacing it until we have something
better, sound resonable?

It is appealing to be able to talk to the database via some
sgml/html/xml format. A proxy would allow this too, and it certainly
something that would be nice. Certainly no reason we can't add it, and
if we start out as a proxy, we don't have to add it to the backend
itself.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Fri, 1 Jan 1999, Bruce Momjian wrote:

The pros, IMHO:
* XML interfaces better to the object model of pgsql itself
* XML interfaces better to XML-viewer, like next generation of
web browsers.

With a little imagination we can at some point in the future forget
about making clients for the databases, just point your webbrowser
at the serverport a make both SELECTs (displays) and INSERT/UPDATE
(forms) with a few lines of javascript.

The con:
* We have a good stable protocol but a little simplistic.
Anything new is not as good until it has matured.

Thus I not suggesting replacing it until we have something
better, sound resonable?

It is appealing to be able to talk to the database via some
sgml/html/xml format. A proxy would allow this too, and it certainly
something that would be nice. Certainly no reason we can't add it, and
if we start out as a proxy, we don't have to add it to the backend
itself.

And, of course, as it matures, its something we can always roll
into the backend :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Goran Thyni <goran@kirra.net> writes:

The pros, IMHO:
* XML interfaces better to the object model of pgsql itself

CORBA does that as well or better, I suspect.

* XML interfaces better to XML-viewer, like next generation of
web browsers.

So? I can't get excited about being able to view raw server output in
a web browser --- it seems to me that any interesting web application
of Postgres is going to involve an intermediate layer of code anyway
(to convert client actions into SQL commands, adorn the output with page
headers and buttons and so forth, etc etc). I don't see anything about
XML that eliminates the need for that intermediate layer, and I don't
see much about XML that makes that layer easier to write.

With a little imagination we can at some point in the future forget
about making clients for the databases, just point your webbrowser
at the serverport a make both SELECTs (displays) and INSERT/UPDATE
(forms) with a few lines of javascript.

I think you drastically underestimate the amount of glue code that will
be needed, and overestimate the advantage of having the results come
back already formatted in an HTML-like fashion. (OK, it'd make direct
display a little easier, but what if you have to extract some data for
processing? Writing an XML parser in Javascript doesn't sound like a
piece of cake to me.)

If XML had big benefits for non-web-browser front ends, it might still
be a win, but I'm not seeing anything much there either.

It should also be pointed out that XML isn't a *protocol*, just a
data representation. If you choose to represent the results of SELECTs
in XML, that still leaves you with all the other aspects of FE/BE
communication yet to be designed.

I thought the proposal to build a CORBA-based interface for Postgres
was pretty interesting and worthy of further study ... I'd rather see
us put our time into that. (I am certainly not wedded to the current
FE/BE protocol; it gets the job done, but it's crufty and has
performance limitations.)

regards, tom lane

Tom Lane wrote:

Goran Thyni <goran@kirra.net> writes:

The pros, IMHO:
* XML interfaces better to the object model of pgsql itself

CORBA does that as well or better, I suspect.

* XML interfaces better to XML-viewer, like next generation of
web browsers.

So? I can't get excited about being able to view raw server output in
a web browser --- it seems to me that any interesting web application
of Postgres is going to involve an intermediate layer of code anyway
(to convert client actions into SQL commands, adorn the output with page
headers and buttons and so forth, etc etc). I don't see anything about
XML that eliminates the need for that intermediate layer, and I don't
see much about XML that makes that layer easier to write.

This is what DOM is for, read on.

With a little imagination we can at some point in the future forget
about making clients for the databases, just point your webbrowser
at the serverport a make both SELECTs (displays) and INSERT/UPDATE
(forms) with a few lines of javascript.

I think you drastically underestimate the amount of glue code that will
be needed, and overestimate the advantage of having the results come
back already formatted in an HTML-like fashion. (OK, it'd make direct
display a little easier, but what if you have to extract some data for
processing? Writing an XML parser in Javascript doesn't sound like a
piece of cake to me.)

The XML parser is in the browser. It parses to XML-code into a DOM which
is easily accessed from javascript.

The step are:
1/ a DTD defines the parsing of our document type into the DOM
2/ a style sheet determines the layout on our output device
3/ javascript access to the DOM for making tweak to layout and
functions.

The client side is still immature and some parts are in still flux.

If XML had big benefits for non-web-browser front ends, it might still
be a win, but I'm not seeing anything much there either.

This is a chicken-egg problem,
we must have data to make clients interesting
and
we must have clients to make server output interesting

CORBA has the same problem, we must start somewhere.
As I am a "server-side kind of guy", I will start there
and hope clients catch up.

On the client side I put most faith in "Gecko"
the new layout engine from mozilla.org.

It should also be pointed out that XML isn't a *protocol*, just a
data representation. If you choose to represent the results of SELECTs
in XML, that still leaves you with all the other aspects of FE/BE
communication yet to be designed.

HTTP and/or IIOP/CORBA is useable for that.

I thought the proposal to build a CORBA-based interface for Postgres
was pretty interesting and worthy of further study ... I'd rather see
us put our time into that.

One does not rule out the other,
I think that much of the object functionality
of both ideas has much in common with seperate
output mechanisms, like:

---------------------------------------
| PgSQL Core |
---------------------------------------
| Object Data Access | Base |
---------------------------- |
| CORBA | XML | protocol |
---------------------------------------
| Clients |
---------------------------------------

Anyway, thanks for your input Tom.
Questioning my ideas, forces me to develop them
and fill in the blanks, which is "good thing(tm)".
Keep arguments, ideas and questions coming!

mvh,
--
-----------------
G�ran Thyni
This is Penguin Country. On a quiet night you can hear Windows NT
reboot!

Anyone doing serious SGML/XML playing (import/export) from PostgreSQL?

I'm going to spend time writing a "journal", which is a generic
repository
for sequencital storage of incoming XML.

Thanks!

Clark