Skip site navigation (1) Skip section navigation (2)

Re: Re: From TODO, XML?

From: "Ken Hirsch" <kenhirsch(at)myself(dot)com>
To: "mlw" <markw(at)mohawksoft(dot)com>, "Frank Ch(dot) Eigler" <fche(at)redhat(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: From TODO, XML?
Date: 2001-07-29 15:50:05
Message-ID: 002501c11846$282b7ac0$6e863dd0@hppav (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
mlw <markw(at)mohawksoft(dot)com> wrote:

> "Frank Ch. Eigler" wrote:
> > : So a parser that can scan a DTD and make a usable create table (...)
> > : line would be very helpful. [...]
> >
> > Hmm, but hierarchically structured documents such as XML don't map
> > well to a relational model.  The former tend to be recursive (e.g.,
> > have more levels of containment than the one or two that might be
> > mappable to tables and columns.)
> Yes!!! Exactly, being able to understand the recursive nature of XML and
> relations on the fly would be a very cool feature.

I think there is a pretty straight forward mapping, except for one possible

If an element, say <address>, is contained within another element, say
<employee>, it could either be a column (or group of columns) in an Employee
table, or it could be a table Address which references Employee.

When you say "create relations on the fly", what exactly do you mean?  I can
see it would be handy to have CREATE TABLE statements written for you, but
it seems likely that a human would want to edit them before the tables are
actually created.  You cannot infer much type information from the DTD.  I
don't think there's a way to infer a primary key from a DTD, so you would
want to either specify one or add a serial column (or perhaps that would
always be done automatically).  An XML schema would have more information,
of course.

In response to


pgsql-hackers by date

Next:From: mlwDate: 2001-07-29 16:19:48
Subject: Re: Re: From TODO, XML?
Previous:From: Bruce MomjianDate: 2001-07-29 05:08:09
Subject: Re: Revised Patch to allow multiple table locks in "Unison"

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group