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 K
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 p
Josh Berkus 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
---
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
>
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
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
Please let us know if about any concerns, objections the proposed change may
cause.
Best regards,
Jason Lucas, Sergey Ten
SourceLabs
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 11, 2005 7:11 PM
To: Sergey Ten
Cc: pgs
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
> C
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 a
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
'Christopher Kings-Lynne'; pgsql-
> [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
pgsql-
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] patches for items from TODO list
>
> Dnia 13-05-2005, pią o godzinie 16:01 -0700, Sergey Ten napisał(a):
>
> >
> >
> >
> > Jackso
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
Dnia 13-05-2005, piÄ o godzinie 16:01 -0700, Sergey Ten napisaÅ(a):
>
>
>
> Jackson, Sam
> \h
>
>
> It is "perfect".
>
>
>
>
>
>
>
Why didn't you do something to th
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 to contr
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 versi
gsql-hackers@postgresql.org; [EMAIL PROTECTED]
> 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".
> >
>
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 r
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
20 matches
Mail list logo