Thread: XML export function signatures
Here are the proposed signatures for the XML export functions. While I have seen the output formats in use elsewhere, I could not find any useful information on how to invoke these mappings, so the following is purely my own invention. table_to_xml(tbl regclass, nulls boolean, tableforest boolean, targetns text) RETURNS xml query_to_xml(query text, nulls boolean, tableforest boolean, targetns text) RETURNS xml table_to_xmlschema(tbl regclass, nulls boolean, tableforest boolean, targetns text) RETURNS xml query_to_xmlschema(query text, nulls boolean, tableforest boolean, targetns text) RETURNS xml table_to_xml_and_xmlschema(tbl regclass, nulls boolean, tableforest boolean, targetns text) RETURNS xml query_to_xml_and_xmlschema(query text, nulls boolean, tableforest boolean, targetns text) RETURNS xml cursor_get_xml(cursor refcursor, count int, nulls boolean, tableforest boolean, targetns text) RETURNS xml cursor_to_xmlschema(cursor refcursor, nulls boolean, tableforest boolean, targetns text) RETURNS xml The table_* variants export named tables, and the output will have some degree of catalog information about the tables, which will have to be omitted for the query_* variants. The cursor_* variants exist for supporting the export of large structures. *_to_xml gives you the data, *_to_xmlschema the associated XML Schema document, and *_to_xml_and_xmlschema gives you both in one XML document and linked together. The argument "nulls" specifies whether to include null values, "tableforest" switches between two alternative ways of representing the data, and "targetns" is the target (XML) namespace. Comments? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Here are the proposed signatures for the XML export functions. > > While I have seen the output formats in use elsewhere, I could not find > any useful information on how to invoke these mappings, so the > following is purely my own invention. > > table_to_xml(tbl regclass, nulls boolean, tableforest boolean, targetns text) RETURNS xml > query_to_xml(query text, nulls boolean, tableforest boolean, targetns text) RETURNS xml > table_to_xmlschema(tbl regclass, nulls boolean, tableforest boolean, targetns text) RETURNS xml > query_to_xmlschema(query text, nulls boolean, tableforest boolean, targetns text) RETURNS xml > table_to_xml_and_xmlschema(tbl regclass, nulls boolean, tableforest boolean, targetns text) RETURNS xml > query_to_xml_and_xmlschema(query text, nulls boolean, tableforest boolean, targetns text) RETURNS xml > cursor_get_xml(cursor refcursor, count int, nulls boolean, tableforest boolean, targetns text) RETURNS xml > cursor_to_xmlschema(cursor refcursor, nulls boolean, tableforest boolean, targetns text) RETURNS xml > > The table_* variants export named tables, and the output will have some > degree of catalog information about the tables, which will have to be > omitted for the query_* variants. The cursor_* variants exist for > supporting the export of large structures. > > *_to_xml gives you the data, *_to_xmlschema the associated XML Schema > document, and *_to_xml_and_xmlschema gives you both in one XML document > and linked together. > > The argument "nulls" specifies whether to include null values, > "tableforest" switches between two alternative ways of > representing the data, and "targetns" is the target (XML) > namespace. > > > > Looks fairly sound. . table_to_xml_and_xmlschema seems like a mouthful - can we shorten it a bit? . what are the two ways of representing data that tableforest distinguishes? . can we have versions that supply defaults for params after the first? cheers andrew
Andrew Dunstan wrote: > . table_to_xml_and_xmlschema seems like a mouthful - can we shorten > it a bit? Well, it gives you back a mouthful of data, too. :) > . what are the two ways of representing data that tableforest > distinguishes? tableforest = false gives you something like <tablename><row> <!-- where "row" is constant --> <col1name>data</col1name> <col2name>data</col2name></row><row> ...</row>... </tablename> tableforest = true gives you something like <tablename><col1name>data</col1name><col2name>data</col2name> </tablename> <tablename>... </tablename> ... > . can we have versions that supply defaults for params after the > first? I would like that, but I don't know what the defaults should be. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > tableforest = false gives you something like > > <tablename> > ... > </tablename> > > tableforest = true gives you something like > > <tablename> > ... > </tablename> > > <tablename> > ... > </tablename> > > ... > How do you define the table name when fetching data using a join, union etc. where the data doesn't necessarily originate from a single table? Could it be an idea to allow the table name to be specified as a parameter to the function? Another neat feature would be if you could specify a set of columns which should be represented as attributes instead of nodes. -- Tommy
Tommy Gildseth wrote: > How do you define the table name when fetching data using a join, > union etc. where the data doesn't necessarily originate from a single > table? If you use the query_to_xml function, then I just write "<table>" without any particular name. > Another neat feature would be if you could specify a set of columns > which should be represented as attributes instead of nodes. I'm sure there are plenty of possible neat features, but most of these can be implemented by passing the result through an XSLT transformation. -- Peter Eisentraut http://developer.postgresql.org/~petere/