Jim, the big advantage of the CMS insertable view trick is that you don't hit any limits on number of parameters as you would
with __new things in postgres. It supports defaults in the
metadata (and in the table definition). The only disadvantage would be if you really do need to do anything fancy in the
new method (although for CR items that seems mostly not
to be the case). Of course if you are talking about small bitesized things with few attributes then that is not an issue. For photos for example if you create attributes for
the useful exif data fields you already have more that 16 fields. Given how many things are gobbled up for just the basic metadata this seems to be a serious problem
for most types.
Talli, there is a table cr_revisions_attributes which is
supposed to hold an XML representation for a given content revision and there
are things in oracle to generate the XML (although I have
not looked to see if this is present in postgres). The
intent is to use it as a secondary representation of the given
revision (intended originally for indexing I think but there is no reason you couldn't use it to feed an XSL styling step
or embed in a larger xml document to export a content collection). It's not really related to RSS at all (other than both things are XML). There is not any provision for
making the primary datastore XML rather than table based, although you can of course store XML in the content field,
there just is no pleasant way to query it other than with full text search really or other RDBMS things to it
(like sorting or updating).
