XML export function signatures

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/