Sean Chittenden kirjutas R, 30.05.2003 kell 23:20:
> > > I assume we are not moving in the XML/psql direction, right? We
> > > want it int he backend, or the psql HTML converted to XHTML?
> >
> > I don't think a consensus was ever reached. It would certainly be
> > better if this was done on the backend, but that seems to be a long
> > time away, and some have argued that it is not the job of the engine
> > to do this anyway.
>
> Few points for the archives regarding XML and databases (spent 9mo
> working on this kinda stuff during the .com days):
>
> *) Use libxml2. MIT Licensed, most complete opensource XML
> implementation available, and fast. See the XML benchmarks on
> sf.net for details. To avoid library naming conflicts, the library
> should likely be renamed to pgxml.so and imported into the src
> tree. Mention java in this context and risk being clubbed to death.
Agree completely on all points ;)
> *) There should be two storage formats for XML data:
>
> a) DOM-esque storage: broken down xmlNodes. This is necessary for
> indexing specific places in documents (ala XPath queries).
> Actual datums on the disk should be similar in structure to the
> xmlNode struct found in libxml2 (would help with the
> serialization in either direction). In database xslt
> transformations are also possible with the data stored this way.
>
> b) SAX-esque storage: basically a single BYTEA/TEXT column. Not
> all documents need to be indexed/searchable and SAX processing
> of data is generally more efficient if you don't know what
> you're looking for. This format is the low hanging fruit
> though.
I think that Oleg and Todor very recently proposed somethink that could
use b) and still provide indexed access.
Most flexible would be some way to define, how much of a tree is kept
together, as xmlNode/tuple would probably be too much overhead for most
operations, whereas xmlFile/tuple would also, just for other ops;)
--------------
Hannu
