Storing the XML text has problems - you have to parse it every time you want something - that has to cause a huge performance hit.
I use XML a lot for all sorts of purposes, but it is appropriate for data transfer rather than data storage, IMNSHO.
cheers
andrew
Christopher Kings-Lynne wrote:
Do this:
1. Create a new type called 'xml', based on text.
2. The xmlin function for that type will validate what you are enterering is XML
3. Create new functions to implement XPath, SAX, etc. on the xml type.
4. Extend the contrib/ltree gist-based tree indexing scheme to work on xml and hence the operations in no.3 above are really fast...
Chris
Andrew Dunstan wrote:
Christopher Browne wrote:
But I think back to the XML generator I wrote for GnuCash; it has the
notion of building up a hierarchy of entities and attributes, each of
which is visible as an identifyable object of some sort. Mapping that
onto a set of PostgreSQL relations wouldn't work terribly well.
*nod* I have tried this several times - it just doesn't work well, because the maps are too different.
You could do something like this:
. a table for each element type, fields being the attributes, plus the node id.
. a table to tie everything together (parent_id, child_id, child_order, child_type).
In theory you could even generate the DB schema from an XML schema and evaluate it with XPath-like expressions.
But why put yourself to such bother? I have never found a good reason to do this sort of thing.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
