Thread: support for printing/exporting xml
hello, please find attached my support for printing/exporting xml from postgresql. psql has been modified to take an additional command line argument (-M) to print xml and the file fe-printxml.c has been added. additionally, i have added an extra function to libpq, PGresult_as_xml thanks, b __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Attachment
Brian Moore <brianmooreca@yahoo.com> writes: > please find attached my support for printing/exporting > xml from postgresql. A few quick comments: - why is it necessary to include an entire hash table implementation? Why does this code require a hash table to begin with, considering the relatively small size of pg_type? ISTM something far simpler (for example, a dynamically allocated sorted array and a binary search) would be sufficient. - testing code doesn't belong in libpq - you'll need to update the libpq docs - you should follow the libpq API naming convention: the function should be look like some variant of PQresultAsXML() - context diffs are the preferred format -Neil
--- Neil Conway <neilc@samurai.com> wrote: > Brian Moore <brianmooreca@yahoo.com> writes: > > please find attached my support for printing/exporting > > xml from postgresql. > > A few quick comments: > > - why is it necessary to include an entire hash table implementation? > Why does this code require a hash table to begin with, considering > the relatively small size of pg_type? ISTM something far simpler > (for example, a dynamically allocated sorted array and a binary > search) would be sufficient. it's not necessary. i ran tests and the hashtable lookup was faster (though not by too much) than the bsearch for the data with which i populated the table. > - testing code doesn't belong in libpq agreed. that was an obvious error -- i'll look into that. > - you'll need to update the libpq docs agreed. i haven't updated the docs yet -- i was waiting to see if the patch got accepted. if the patch will be accepted i will do a lot more work for libpq. > > - you should follow the libpq API naming convention: the function > should be look like some variant of PQresultAsXML() okay. i didn't get feedback on this when i posted the first time. this is easy to change. > > - context diffs are the preferred format yeah, sorry, i remembered that right after sending the patch. "-Naur" is so cute (of backus fame) that it's hard to shake. any future patches will be in context format. thanks lots for the feedback, b > > -Neil > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Brian Moore <brianmooreca@yahoo.com> writes: > it's not necessary. i ran tests and the hashtable lookup was faster > (though not by too much) than the bsearch for the data with which i > populated the table. Right -- I'd expect the performance difference between the two to be pretty negligible for even the largest pg_type catalogs. So do you agree that using bsearch here is preferable, or no? -Neil
I assume the group agreed that adding XML to libpq was the way to handle
XML, with a hook in psql to call it.
I also see this copyright on one of the files:
+ * Hash Table Data Type
+ * Copyright (C) 1997 Kaz Kylheku <kaz@ashi.footprints.net>
+ *
+ * Free Software License:
+ *
+ * All rights are reserved by the author, with the following exceptions:
+ * Permission is granted to freely reproduce and distribute this software,
+ * possibly in exchange for a fee, provided that this copyright notice appears
+ * intact. Permission is also granted to adapt this software to produce
+ * derivative works, as long as the modified versions carry this copyright
+ * notice and additional notices stating that the work has been modified.
+ * This source code may be translated into executable form and incorporated
+ * into proprietary software; there is no requirement for such software to
+ * contain a copyright notice related to this source.
+ *
I assume this copyright is compatible with our BSD copyright.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Brian Moore wrote:
> hello,
>
> please find attached my support for printing/exporting
> xml from postgresql. psql has been modified to take
> an additional command line argument (-M) to print xml
> and the file fe-printxml.c has been added. additionally,
> i have added an extra function to libpq, PGresult_as_xml
>
> thanks,
>
> b
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free web site building tool. Try it!
> http://webhosting.yahoo.com/ps/sb/
Content-Description: postgresql-7.4.1.add_xml_export_support.patch
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.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
Patch removed. Requires more discussion. --------------------------------------------------------------------------- Brian Moore wrote: > hello, > > please find attached my support for printing/exporting > xml from postgresql. psql has been modified to take > an additional command line argument (-M) to print xml > and the file fe-printxml.c has been added. additionally, > i have added an extra function to libpq, PGresult_as_xml > > thanks, > > b > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free web site building tool. Try it! > http://webhosting.yahoo.com/ps/sb/ Content-Description: postgresql-7.4.1.add_xml_export_support.patch [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.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
Peter Eisentraut wrote: > Bruce Momjian wrote: > > Peter Eisentraut wrote: > > > Bruce Momjian wrote: > > > > I assume the group agreed that adding XML to libpq was the way to > > > > handle XML, with a hook in psql to call it. > > > > > > I'm not sure about that, but we certainly disagree with this kind > > > of nonstandard XML when there is a perfectly good standard out > > > there. > > > > OK, can you elaborate? What is the non-standard part? His choice of > > tags? > > Yes. The SQL/XML standard has been discussed several times on this > list. Additionally, it has been mentioned that an implementation in > libpq is too specific for some. Some people want streaming interfaces, > some want it in the backend, etc. I think there are going to be many > implementations of the XML theme, so I think it's premature to adopt > one of them into libpq. OK, what do you suggest the poster does now? Use SQL/XML? Move it into the backend? -- 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
Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian wrote: > > > I assume the group agreed that adding XML to libpq was the way to > > > handle XML, with a hook in psql to call it. > > > > I'm not sure about that, but we certainly disagree with this kind > > of nonstandard XML when there is a perfectly good standard out > > there. > > OK, can you elaborate? What is the non-standard part? His choice of > tags? Yes. The SQL/XML standard has been discussed several times on this list. Additionally, it has been mentioned that an implementation in libpq is too specific for some. Some people want streaming interfaces, some want it in the backend, etc. I think there are going to be many implementations of the XML theme, so I think it's premature to adopt one of them into libpq.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I assume the group agreed that adding XML to libpq was the way to handle
> XML, with a hook in psql to call it.
My recollection was that we had not agreed we liked this patch?
regards, tom lane
Peter Eisentraut wrote: > Bruce Momjian wrote: > > I assume the group agreed that adding XML to libpq was the way to > > handle XML, with a hook in psql to call it. > > I'm not sure about that, but we certainly disagree with this kind of > nonstandard XML when there is a perfectly good standard out there. OK, can you elaborate? What is the non-standard part? His choice of tags? -- 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
Bruce Momjian wrote: > I assume the group agreed that adding XML to libpq was the way to > handle XML, with a hook in psql to call it. I'm not sure about that, but we certainly disagree with this kind of nonstandard XML when there is a perfectly good standard out there.
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Your patch has been added to the PostgreSQL unapplied patches list > at: In addition to the design problems raised elsewhere, I just wanted to add that there are as-yet-unaddressed implementation issues with this patch: I have yet to see a convincing argument for adding an entire hash table implementation to libpq merely for the sake of this functionality. -Neil