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.
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
Sergey Ten wrote:
Markus,
Thank you for your reply.
We considered embedding of an XML schema first followed by data. We decided
to stick to our current data format to make sure stateless XML parsers can
process it as well. Would it be better to add an option to the COPY command,
to allow
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
SourceLabs
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 11, 2005 7:11 PM
To: Sergey Ten
Cc: pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
Subject: Re: [HACKERS] patches for items from TODO list
Sergey Ten wrote:
Hello all,
We would like
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 --
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
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
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
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
]
Subject: Re: [HACKERS] patches for items from TODO list
Dnia 13-05-2005, pi o godzinie 16:01 -0700, Sergey Ten napisa(a):
?xml version='1.0'?
table
row
col name='col1' null='n'Jackson, Sam/col
col name='col2' null='n'\h/col
/row
row
-
[EMAIL PROTECTED]; [EMAIL PROTECTED]
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
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
Dnia 13-05-2005, pi o godzinie 16:01 -0700, Sergey Ten napisa(a):
?xml version='1.0'?
table
row
col name='col1' null='n'Jackson, Sam/col
col name='col2' null='n'\h/col
/row
row
col name='col1' null='n'It is quot;perfectquot;./col
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
@postgresql.org; [EMAIL PROTECTED]
Subject: Re: [HACKERS] patches for items from TODO list
Sergey Ten wrote:
Hello all,
We would like to contribute to the Postgresql community by implementing
the following items from the TODO list
(http://developer.postgresql.org/todo.php):
. Allow COPY
]
Subject: Re: [HACKERS] patches for items from TODO list
Please check the web site version. Someone has already implemented
Allow COPY to optionally include column headings in the first line.
As far as XML, there has been discussion on where that should be done?
In the backend, libpq
Sergey Ten wrote:
Thank you to all who replied for your time.
We have checked http://momjian.postgresql.org/cgi-bin/pgpatches and
http://momjian.postgresql.org/cgi-bin/pgpatches2, and could not find
patches
with words copy or xml in the subject. Could you please clarify what
the
website version
Hello all,
We would like to contribute to the Postgresql community by implementing
the following items from the TODO list
(http://developer.postgresql.org/todo.php):
. Allow COPY to understand \x as a hex byte . Allow COPY to optionally
include column headings in the first line . Add XML output
Sergey Ten wrote:
Hello all,
We would like to contribute to the Postgresql community by implementing
the following items from the TODO list
(http://developer.postgresql.org/todo.php):
. Allow COPY to understand \x as a hex byte . Allow COPY to optionally
include column headings in the
Please check the web site version. Someone has already implemented
Allow COPY to optionally include column headings in the first line.
As far as XML, there has been discussion on where that should be done?
In the backend, libpq, or psql. It will need discussion on hackers. I
assume you have
21 matches
Mail list logo
