Neil,

We think that putting it in the backend will make access from other
components easier.

Thank you,
Sergey

> -----Original Message-----
> From: Neil Conway [mailto:neilc@samurai.com]
> Sent: Tuesday, May 17, 2005 7:11 PM
> To: Sergey Ten
> Cc: 'Bruce Momjian'; 'Christopher Kings-Lynne'; pgsql-
> hackers@postgresql.org; jason@sourcelabs.com
> Subject: Re: [HACKERS] patches for items from TODO list
>
> Sergey Ten wrote:
> > After a careful consideration we decided to
> > - put XML implementation in the backend
>
> What advantage does putting the XML output mode in the backend provide?
>
> -Neil


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Sergey Ten wrote:
> We think that putting it in the backend will make access from other
> components easier.

In what way?

It seems to me that this can be done just as easily in a client
application / library, without cluttering the backend with yet another
COPY output format. It would also avoid the need to mandate a single XML
schema -- different clients will likely have different requirements.
Since I am skeptical of the value of this feature in the first place, I
think it would do less damage if implemented outside the backend.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Neil Conway wrote:
> Sergey Ten wrote:
> > We think that putting it in the backend will make access from other
> > components easier.
>
> In what way?
>
> It seems to me that this can be done just as easily in a client
> application / library, without cluttering the backend with yet another
> COPY output format. It would also avoid the need to mandate a single XML
> schema -- different clients will likely have different requirements.
> Since I am skeptical of the value of this feature in the first place, I
> think it would do less damage if implemented outside the backend.

We considered putting XML in psql or libpq in the past, but the problem
is that interfaces like jdbc couldn't take advantage of it. I do think
it needs to be in the backend, and I think that is the agreement we had
in the past.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Bruce Momjian wrote:
> We considered putting XML in psql or libpq in the past, but the problem
> is that interfaces like jdbc couldn't take advantage of it.

Well, you could implement it as a C UDF and use SPI. Or write it as a C
client library, and use JNI. Or just provide a Java implementation --
it's not like the COPY -> XML transformation is very complex.

To restate the case:

- I don't see how this feature is useful. Perhaps I'm mistaken, but I
don't think there's a lot of user demand for it (feel free to
demonstrate the contrary)

- The COPY -> XML transformation is trivial -- it would be easy for
clients to roll their own. At the same time, there is no standard or
canonical XML representation for COPY output, and I can easily imagine
different clients needing different representations. So there is limited
value in providing a single, inflexible backend implementation.

- There's no need for it to be in the backend, anyway. Perhaps if there
were overwhelming demand for this functionality, we would need to
provide it for all client libraries and the easiest solution would be to
put it in the backend, but I don't think that's the case.

If people really think XML COPY output mode is useful, why not implement
it client-side first and host it on pgfoundry? If lots of people are
using the client-side code, we can consider moving it into the core
distribution or the backend itself at that point.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Neil Conway wrote:
> Bruce Momjian wrote:
> > We considered putting XML in psql or libpq in the past, but the problem
> > is that interfaces like jdbc couldn't take advantage of it.
>
> Well, you could implement it as a C UDF and use SPI. Or write it as a C
> client library, and use JNI. Or just provide a Java implementation --
> it's not like the COPY -> XML transformation is very complex.
>
> To restate the case:
>
> - I don't see how this feature is useful. Perhaps I'm mistaken, but I
> don't think there's a lot of user demand for it (feel free to
> demonstrate the contrary)
>
> - The COPY -> XML transformation is trivial -- it would be easy for
> clients to roll their own. At the same time, there is no standard or
> canonical XML representation for COPY output, and I can easily imagine
> different clients needing different representations. So there is limited
> value in providing a single, inflexible backend implementation.
>
> - There's no need for it to be in the backend, anyway. Perhaps if there
> were overwhelming demand for this functionality, we would need to
> provide it for all client libraries and the easiest solution would be to
> put it in the backend, but I don't think that's the case.
>
> If people really think XML COPY output mode is useful, why not implement
> it client-side first and host it on pgfoundry? If lots of people are
> using the client-side code, we can consider moving it into the core
> distribution or the backend itself at that point.

All I can say is that we rejected an XML in the client patch a long time
ago and the discussion was that it belongs in the backend so everyone
can use it. I don't use XML myself so I have no opinion. We need
people who need XML output to comment in this thread.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Folks,

> - The COPY -> XML transformation is trivial -- it would be easy for
> clients to roll their own. At the same time, there is no standard or
> canonical XML representation for COPY output, and I can easily imagine
> different clients needing different representations. So there is limited
> value in providing a single, inflexible backend implementation.

I'm going to second Neil here. This feature becomes useful *only* when there
is a certified or de-facto universal standard XML representation for database
data. Then I could see a case for it. But there isn't.

Feel free to throw it on pgFoundry, though.

--
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Josh Berkus <josh@agliodbs.com> writes:
> I'm going to second Neil here.

I think the same --- given the points about lack of standardization,
it seems premature to put this into the backend. I'd be for it if
there were a clear standard, but ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

> I'm going to second Neil here. This feature becomes useful *only* when there
> is a certified or de-facto universal standard XML representation for database
> data. Then I could see a case for it. But there isn't.

We've done it in phpPgAdmin (we made up our own standard), and a couple
of people use it. I also do not think that it should be in the backend
until there is a standard. Here is what phpPgAdmin produces (note NULL
handling):

<?xml version="1.0" encoding="UTF-8" ?>
<data>
<header>
<column name="feature_id" type="varchar" />
<column name="feature_name" type="varchar" />
<column name="is_supported" type="varchar" />
<column name="is_verified_by" type="varchar" />
<column name="comments" type="varchar" />
</header>
<records>
<row>
<column name="feature_id">PKG000</column>
<column name="feature_name">Core</column>
<column name="is_supported">NO</column>
<column name="is_verified_by" null="null"></column>
<column name="comments" null="null"></column>
</row>
<row>
<column name="feature_id">PKG001</column>
<column name="feature_name">Enhanced datetime facilities</column>
<column name="is_supported">YES</column>
<column name="is_verified_by" null="null"></column>
<column name="comments" null="null"></column>
</row>
<row>
<column name="feature_id">PKG002</column>
<column name="feature_name">Enhanced integrity management</column>
<column name="is_supported">NO</column>
<column name="is_verified_by" null="null"></column>
<column name="comments" null="null"></column>
</row>
<row>
<column name="feature_id">PKG003</column>
<column name="feature_name">OLAP facilities</column>
<column name="is_supported">NO</column>
<column name="is_verified_by" null="null"></column>
<column name="comments" null="null"></column>
</row>
<row>
<column name="feature_id">PKG004</column>
<column name="feature_name">PSM</column>
<column name="is_supported">NO</column>
<column name="is_verified_by" null="null"></column>
<column name="comments">PL/pgSQL is similar.</column>
</row>
<row>
<column name="feature_id">PKG005</column>
<column name="feature_name">CLI</column>
<column name="is_supported">NO</column>
<column name="is_verified_by" null="null"></column>
<column name="comments">ODBC is similar.</column>
</row>
<row>
<column name="feature_id">PKG006</column>
<column name="feature_name">Basic object support</column>
<column name="is_supported">NO</column>
<column name="is_verified_by" null="null"></column>
<column name="comments" null="null"></column>
</row>
<row>
<column name="feature_id">PKG007</column>
<column name="feature_name">Enhanced object support</column>
<column name="is_supported">NO</column>
<column name="is_verified_by" null="null"></column>
<column name="comments" null="null"></column>
</row>
<row>
<column name="feature_id">PKG008</column>
<column name="feature_name">Active database</column>
<column name="is_supported">NO</column>
<column name="is_verified_by" null="null"></column>
<column name="comments" null="null"></column>
</row>
<row>
<column name="feature_id">PKG010</column>
<column name="feature_name">OLAP</column>
<column name="is_supported">NO</column>
<column name="is_verified_by" null="null"></column>
<column name="comments">NO</column>
</row>
</records>
</data>

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

minor nit: the null attribute should take XMLSchema boolean type values:
{true, false, 1, 0}

More importantly, how do you handle array or record type fields? If they
are just opaque text I don't think that's what I at least would want
from XML output routines.

cheers

andrew

Christopher Kings-Lynne wrote:

>> I'm going to second Neil here. This feature becomes useful *only*
>> when there is a certified or de-facto universal standard XML
>> representation for database data. Then I could see a case for it.
>> But there isn't.
>
>
> We've done it in phpPgAdmin (we made up our own standard), and a
> couple of people use it. I also do not think that it should be in the
> backend until there is a standard. Here is what phpPgAdmin produces
> (note NULL handling):
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <data>
> <header>
> <column name="feature_id" type="varchar" />
> <column name="feature_name" type="varchar" />
> <column name="is_supported" type="varchar" />
> <column name="is_verified_by" type="varchar" />
> <column name="comments" type="varchar" />
> </header>
> <records>
> <row>
> <column name="feature_id">PKG000</column>
> <column name="feature_name">Core</column>
> <column name="is_supported">NO</column>
> <column name="is_verified_by" null="null"></column>
> <column name="comments" null="null"></column>
> </row>
> <row>
> <column name="feature_id">PKG001</column>
> <column name="feature_name">Enhanced datetime
> facilities</column>
> <column name="is_supported">YES</column>
> <column name="is_verified_by" null="null"></column>
> <column name="comments" null="null"></column>
> </row>
> <row>
> <column name="feature_id">PKG002</column>
> <column name="feature_name">Enhanced integrity
> management</column>
> <column name="is_supported">NO</column>
> <column name="is_verified_by" null="null"></column>
> <column name="comments" null="null"></column>
> </row>
> <row>
> <column name="feature_id">PKG003</column>
> <column name="feature_name">OLAP facilities</column>
> <column name="is_supported">NO</column>
> <column name="is_verified_by" null="null"></column>
> <column name="comments" null="null"></column>
> </row>
> <row>
> <column name="feature_id">PKG004</column>
> <column name="feature_name">PSM</column>
> <column name="is_supported">NO</column>
> <column name="is_verified_by" null="null"></column>
> <column name="comments">PL/pgSQL is similar.</column>
> </row>
> <row>
> <column name="feature_id">PKG005</column>
> <column name="feature_name">CLI</column>
> <column name="is_supported">NO</column>
> <column name="is_verified_by" null="null"></column>
> <column name="comments">ODBC is similar.</column>
> </row>
> <row>
> <column name="feature_id">PKG006</column>
> <column name="feature_name">Basic object support</column>
> <column name="is_supported">NO</column>
> <column name="is_verified_by" null="null"></column>
> <column name="comments" null="null"></column>
> </row>
> <row>
> <column name="feature_id">PKG007</column>
> <column name="feature_name">Enhanced object support</column>
> <column name="is_supported">NO</column>
> <column name="is_verified_by" null="null"></column>
> <column name="comments" null="null"></column>
> </row>
> <row>
> <column name="feature_id">PKG008</column>
> <column name="feature_name">Active database</column>
> <column name="is_supported">NO</column>
> <column name="is_verified_by" null="null"></column>
> <column name="comments" null="null"></column>
> </row>
> <row>
> <column name="feature_id">PKG010</column>
> <column name="feature_name">OLAP</column>
> <column name="is_supported">NO</column>
> <column name="is_verified_by" null="null"></column>
> <column name="comments">NO</column>
> </row>
> </records>
> </data>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

I have removed the XML TODO item:

* Add XML output to pg_dump and COPY

We already allow XML to be stored in the database, and XPath queries
can be used on that data using /contrib/xml2. It also supports XSLT
transformations.

---------------------------------------------------------------------------

Josh Berkus wrote:
> Folks,
>
> > - The COPY -> XML transformation is trivial -- it would be easy for
> > clients to roll their own. At the same time, there is no standard or
> > canonical XML representation for COPY output, and I can easily imagine
> > different clients needing different representations. So there is limited
> > value in providing a single, inflexible backend implementation.
>
> I'm going to second Neil here. This feature becomes useful *only* when there
> is a certified or de-facto universal standard XML representation for database
> data. Then I could see a case for it. But there isn't.
>
> Feel free to throw it on pgFoundry, though.
>
> --
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)