On Dec26, 2013, at 21:30 , Florian Pflug wrote:
> On Dec23, 2013, at 18:39 , Peter Eisentraut wrote:
>> On 12/19/13, 6:40 PM, Florian Pflug wrote:
>>> The following example fails for XMLOPTION set to DOCUMENT as well as for
>>> XMLOPTION set to CONTENT.
>>>
>>> select xmlconcat(
>>> xmlparse(
On Dec23, 2013, at 18:39 , Peter Eisentraut wrote:
> On 12/19/13, 6:40 PM, Florian Pflug wrote:
>> The following example fails for XMLOPTION set to DOCUMENT as well as for
>> XMLOPTION set to CONTENT.
>>
>> select xmlconcat(
>>xmlparse(document ']>'),
>>xmlparse(content '')
>> )::text:
On Dec23, 2013, at 03:45 , Robert Haas wrote:
> On Fri, Dec 20, 2013 at 8:16 PM, Florian Pflug wrote:
>> On Dec20, 2013, at 18:52 , Robert Haas wrote:
>>> On Thu, Dec 19, 2013 at 6:40 PM, Florian Pflug wrote:
Solving this seems a bit messy, unfortunately. First, I think we need to
ha
On 12/19/13, 6:40 PM, Florian Pflug wrote:
> The following example fails for XMLOPTION set to DOCUMENT as well as for
> XMLOPTION set to CONTENT.
>
> select xmlconcat(
> xmlparse(document ']>'),
> xmlparse(content '')
> )::text::xml;
The SQL standard specifies that DTDs are dropped b
On Fri, Dec 20, 2013 at 8:16 PM, Florian Pflug wrote:
> On Dec20, 2013, at 18:52 , Robert Haas wrote:
>> On Thu, Dec 19, 2013 at 6:40 PM, Florian Pflug wrote:
>>> Solving this seems a bit messy, unfortunately. First, I think we need to
>>> have some XMLOPTION value which is a superset of all th
On Dec20, 2013, at 18:52 , Robert Haas wrote:
> On Thu, Dec 19, 2013 at 6:40 PM, Florian Pflug wrote:
>> Solving this seems a bit messy, unfortunately. First, I think we need to
>> have some XMLOPTION value which is a superset of all the others - otherwise,
>> dump & restore won't work reliably
On Thu, Dec 19, 2013 at 6:40 PM, Florian Pflug wrote:
> While looking into ways to implement a XMLSTRIP function which extracts the
> textual contents of an XML value and de-escapes them (i.e. > Solving this
> seems a bit messy, unfortunately. First, I think we need to have some
> XMLOPTION val
Hi,
While looking into ways to implement a XMLSTRIP function which extracts the
textual contents of an XML value and de-escapes them (i.e. replaces entity
references by their text equivalent), I've ran into another issue with the XML
type.
XML values can either contain a DOCUMENT or CONTENT. I
On Thu, Sep 13, 2012 at 12:14:41PM -0700, daniela florescu wrote:
> Dear all,
>
> we talked a while ago about a possible integration between Zorba
> (http://www.zorba-xquery.com/html/index), the Apache open source XML (XQuery)
> and JSON query
> (jsoniq.org) processor into Postgress.
>
> I think
Dear all,
we talked a while ago about a possible integration between Zorba
(http://www.zorba-xquery.com/html/index), the Apache open source XML (XQuery)
and JSON query
(jsoniq.org) processor into Postgress.
I think this would add a lot of functionality to Postgres, and the Zorba query
processor
On 05/11/2011 07:00 PM, Noah Misch wrote:
On Wed, May 11, 2011 at 06:17:07PM -0400, Andrew Dunstan wrote:
On 05/09/2011 11:25 PM, Noah Misch wrote:
SELECT xmlcomment(E'\ufffe');
That's a bit harder. Do we want to extend these checks to cover
surrogates and end of plane characters, which are
On Wed, May 11, 2011 at 06:17:07PM -0400, Andrew Dunstan wrote:
> On 05/09/2011 11:25 PM, Noah Misch wrote:
>> SELECT xmlcomment(E'\ufffe');
>
> That's a bit harder. Do we want to extend these checks to cover
> surrogates and end of plane characters, which are the remaining
> forbidden chars? I
On 05/09/2011 11:25 PM, Noah Misch wrote:
I see you've gone with doing it unconditionally. I'd lean toward testing the
library in pg_xml_init and setting a flag indicating whether we need the extra
pass. However, a later patch can always optimize that.
I wasn't terribly keen on the idea,
On Sun, May 08, 2011 at 06:25:27PM -0400, Andrew Dunstan wrote:
> On 04/27/2011 11:41 PM, Noah Misch wrote:
>> On Wed, Apr 27, 2011 at 11:22:37PM -0400, Andrew Dunstan wrote:
>>> On 04/27/2011 05:30 PM, Noah Misch wrote:
To make things worse, the dump/reload problems seems to depend on your
>
On 04/27/2011 11:41 PM, Noah Misch wrote:
On Wed, Apr 27, 2011 at 11:22:37PM -0400, Andrew Dunstan wrote:
On 04/27/2011 05:30 PM, Noah Misch wrote:
To make things worse, the dump/reload problems seems to depend on your version
of libxml2, or something. With git master, a CentOS 5 system with
On 04/27/2011 05:30 PM, Noah Misch wrote:
I'm not sure what to do about the back branches and cases where data is
already in databases. This is fairly ugly. Suggestions welcome.
We could provide a script in (or linked from) the release notes for testing the
data in all your xml columns.
H
On Wed, Apr 27, 2011 at 11:22:37PM -0400, Andrew Dunstan wrote:
> On 04/27/2011 05:30 PM, Noah Misch wrote:
>> To make things worse, the dump/reload problems seems to depend on your
>> version
>> of libxml2, or something. With git master, a CentOS 5 system with
>> 2.6.26-2.1.2.8.el5_5.1 accepts t
On 04/27/2011 05:30 PM, Noah Misch wrote:
I'm not sure what to do about the back branches and cases where data is
already in databases. This is fairly ugly. Suggestions welcome.
We could provide a script in (or linked from) the release notes for testing the
data in all your xml columns.
Ye
On Wed, Apr 27, 2011 at 03:05:30PM -0400, Andrew Dunstan wrote:
> On 04/26/2011 05:11 PM, Noah Misch wrote:
>> On Mon, Apr 25, 2011 at 07:25:02PM -0400, Andrew Dunstan wrote:
>>> I came across this today, while helping a customer. The following will
>>> happily create a piece of XML with an embedde
On 04/26/2011 05:11 PM, Noah Misch wrote:
On Mon, Apr 25, 2011 at 07:25:02PM -0400, Andrew Dunstan wrote:
I came across this today, while helping a customer. The following will
happily create a piece of XML with an embedded ^A:
select xmlelement(name foo, null, E'abc\x01def');
Now, a ^A
On mån, 2011-04-25 at 19:25 -0400, Andrew Dunstan wrote:
> I came across this today, while helping a customer. The following
> will
> happily create a piece of XML with an embedded ^A:
>
> select xmlelement(name foo, null, E'abc\x01def');
>
> Now, a ^A is totally forbidden in XML version 1.0
On Mon, Apr 25, 2011 at 07:25:02PM -0400, Andrew Dunstan wrote:
> I came across this today, while helping a customer. The following will
> happily create a piece of XML with an embedded ^A:
>
>select xmlelement(name foo, null, E'abc\x01def');
>
> Now, a ^A is totally forbidden in XML version
I came across this today, while helping a customer. The following will
happily create a piece of XML with an embedded ^A:
select xmlelement(name foo, null, E'abc\x01def');
Now, a ^A is totally forbidden in XML version 1.0, and allowed but only
as "" or equivalent in XML version 1.1, and n
On 15/10/10 15:08, Tomáš Pospíšil wrote:
Hi Robert,
I would like to contribute for community. Under licence used by PostgreSQL.
So is (or was) there anybody with the same interest as me?
Yes, I've been looking at improving the XML support overall, or at least
working to finish the implemen
Hi Robert,
I would like to contribute for community. Under licence used by PostgreSQL.
So is (or was) there anybody with the same interest as me?
> Původní zpráva
> Od: Robert Haas
> Předmět: Re: [HACKERS] XML schema validation
> Datum: 15.10.2
On Thu, Oct 14, 2010 at 4:26 PM, Tomáš Pospíšil wrote:
> Hi hackers,
>
> I choose (for my master's thesis) support PostgresSQL XML schema validation.
> Is anybody there with suggestions? I had a look at current state and noted
> that there is commented out code for DTD.
>
> My plan is to use lib
Hi hackers,
I choose (for my master's thesis) support PostgresSQL XML schema validation. Is
anybody there with suggestions? I had a look at current state and noted that
there is commented out code for DTD.
My plan is to use libxml2, that have in the last version better support for
DTD, XSD and
Hackers,
I'm interested in tackling some of the todo items in XML category. Being
new to postgres hacking I'm hoping I chose an item that isn't more than
I can chew in the first sitting. One item that has caught my eye that I
(naively) hope isn't a huge todo is:
xpath_exists() is needed. It
Peter Eisentraut wrote:
On ons, 2010-04-28 at 15:21 +0100, Mike Fowler wrote:
xpath_exists() is needed. It checks, whether or not the path specified
exists in the XML value. (W/o this function we need to use weird
"array_dims(xpath(...)) IS NOT NULL" syntax.)
That sounds like a reason
On ons, 2010-04-28 at 15:21 +0100, Mike Fowler wrote:
> xpath_exists() is needed. It checks, whether or not the path specified
> exists in the XML value. (W/o this function we need to use weird
> "array_dims(xpath(...)) IS NOT NULL" syntax.)
That sounds like a reasonable project.
> Is any one e
Hackers,
I'm interested in tackling some of the todo items in XML category. Being
new to postgres hacking I'm hoping I chose an item that isn't more than
I can chew in the first sitting. One item that has caught my eye that I
(naively) hope isn't a huge todo is:
xpath_exists() is needed. It
Peter Eisentraut wrote:
On lör, 2009-12-12 at 11:51 -0500, Andrew Dunstan wrote:
It is certainly legal per XML and XSD specs, and the SQL/XML spec has
annotations using appinfo elements. It would be rather surprising if
the
SQL/XML spec forbade annotations such as I propose. The spec is
m
On lör, 2009-12-12 at 11:51 -0500, Andrew Dunstan wrote:
> It is certainly legal per XML and XSD specs, and the SQL/XML spec has
> annotations using appinfo elements. It would be rather surprising if
> the
> SQL/XML spec forbade annotations such as I propose. The spec is
> mind-bogglingly impene
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
2. What happens when the column name contains characters that would have
to be escaped, such as "<" --- haven't you just replaced one de-escaping
problem with another?
But the difference is that the XML processor will
Andrew Dunstan writes:
> Tom Lane wrote:
>> 2. What happens when the column name contains characters that would have
>> to be escaped, such as "<" --- haven't you just replaced one de-escaping
>> problem with another?
> But the difference is that the XML processor will automatically unescape
> t
Tom Lane wrote:
Andrew Dunstan writes:
I propose that we annotate the schema section RowType elements with the
original names, so we would have something like this in the schema section:
1. Is that legal per the SQL/XML spec?
It is certainly legal per XML and XSD specs, and the
Andrew Dunstan writes:
> I propose that we annotate the schema section RowType elements with the
> original names, so we would have something like this in the schema section:
1. Is that legal per the SQL/XML spec?
2. What happens when the column name contains characters that would have
to be es
I'm doing some work with the output of query_to_xml_and_xmlschema(). The
output is a bit unfortunate in my opinion when the column names in the
query are not legal XML names. We quite reasonably translate the names
so that legal XML names result, but we don't actually put the original
name anyw
On Saturday 11 July 2009 17:37:03 andrzej barszcz wrote:
> Well, best to write this way:
>
> Goal : query splitted to base elements
> Result : xml response from server
> Client : select pg_reparse_query();
> Target: 8.4 version
>
> How : modification of ruleutiles.c
> Not done : UNION etc.
> Not do
Hi,
Well, best to write this way:
Goal : query splitted to base elements
Result : xml response from server
Client : select pg_reparse_query();
Target: 8.4 version
How : modification of ruleutiles.c
Not done : UNION etc.
Not done : as builtin function, I don't know how to do it )))
On Sunday 24 August 2008 19:19:24 Greg Fausak wrote:
> Is there a document that describes the direction Postgres
> will take relative to xml technology?
There is some information at http://wiki.postgresql.org/wiki/XML_Todo, but
these items are mainly aiming to complete the approach taken in 8.3.
Recently Postgres has added a data type 'xml' which allows for
a well formed document to be inserted as a column in a Postgres database.
At the moment it doesnot have much utility, you can *almost* get the
same thing done with a text column. It's obviously the first step.
Is there a document tha
Am Friday, 15. August 2008 schrieb Peter Sampson:
> I've searched the mailing lists,site, docs and Google -- to no avail. Also,
> I see that xslt_process (from xml2) will be deprecated going forward. We're
> building an app that will be used for a long time into the future, and I'd
> like to keep i
Tino, thanks for your reply
I would like to use one of the XML rendering functions like
> table_to_xml_and_xmlschema OR table_to_xml and render the output via XSL,
> preferably in one query.
>
"What do you think would be the benefit of doing that?"
My main reason would be to embed all of the app
Hi,
Peter Sampson wrote:
Hi,
I would like to use one of the XML rendering functions like
table_to_xml_and_xmlschema OR table_to_xml and render the output via
XSL, preferably in one query.
What do you think would be the benefit of doing that?
I've searched the mailing lists,site, docs and G
Hi,
I would like to use one of the XML rendering functions like
table_to_xml_and_xmlschema OR table_to_xml and render the output via XSL,
preferably in one query.
I've searched the mailing lists,site, docs and Google -- to no avail. Also,
I see that xslt_process (from xml2) will be deprecated goi
Thank you all for these kind answers. Cheers, JMP
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, 27 Jun 2008, Jean-Michel Pour? wrote:
Dear friends,
You may know me as I worked a long time ago on pgAdmin I with Dave.
ЪЪAs this is an XML related question and XML is quite new, I am posting
on hackers ML. If any solution is being developped, please inform us.
We would like to develo
Josh Berkus <[EMAIL PROTECTED]> writes:
> Well, anything based on XML data is going to be pretty slow. There's just no
> way to extra data from an XML field without lots of parsing.
I thought there'd been some discussion of storing XML data values in
some kind of pre-parsed format?
I agree that'
Jean-Michel,
> As this is an XML related question and XML is quite new, I am posting
> on hackers ML. If any solution is being developped, please inform us.
How is it XML-related?
> We would like to develop a free REST database (real-estate standard)
> based on a PostgreSQL schema. This is a fr
Dear friends,
You may know me as I worked a long time ago on pgAdmin I with Dave.
As this is an XML related question and XML is quite new, I am posting
on hackers ML.
We would like to develop a free REST database (real-estate standard)
based on a PostgreSQL schema. This is a free solution for f
Dear friends,
You may know me as I worked a long time ago on pgAdmin I with Dave.
As this is an XML related question and XML is quite new, I am posting
on hackers ML. If any solution is being developped, please inform us.
We would like to develop a free REST database (real-estate standard)
base
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> sponge failed the XML regression test once today:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sponge&dt=2007-02-14%2007:30:02
> If i read that correctly we could just add a simple "ORDER BY
> table_name" to that query to get a more rel
sponge failed the XML regression test once today:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sponge&dt=2007-02-14%2007:30:02
If i read that correctly we could just add a simple "ORDER BY
table_name" to that query to get a more reliable result.
Stefan
---(end
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Tue, Feb 13, 2007 at 05:23:56PM +0100, Peter Eisentraut wrote:
>> It turns out that gcc warns about it anyway. Does anyone have some sort
>> of clever recipe to catch warnings more easily than by carefully
>> reading the make output or manually gr
Peter Eisentraut wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> > > From what I can tell, this is because the Assert() puts code (the
> > > do {} loop) *before* the declaration of StringInfoData buf, which
> > > is not permitted.
> >
> > This will fail on every ANSI-C co
On Tue, Feb 13, 2007 at 05:23:56PM +0100, Peter Eisentraut wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> > > From what I can tell, this is because the Assert() puts code (the
> > > do {} loop) *before* the declaration of StringInfoData buf, which
> > > is not permitted.
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > From what I can tell, this is because the Assert() puts code (the
> > do {} loop) *before* the declaration of StringInfoData buf, which
> > is not permitted.
>
> This will fail on every ANSI-C compiler, not just vc. Please fix.
We
Magnus Hagander wrote:
> The latest set of XML changes (I think latest, at least fairly recent)
> broke the win32vc build with asserts enabled. The line:
> Assert(fully_escaped || !escape_period);
>
> From what I can tell, this is because the Assert() puts code (the do {}
> loop) *before* th
On Tue, Feb 13, 2007 at 10:50:30AM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > From what I can tell, this is because the Assert() puts code (the do {}
> > loop) *before* the declaration of StringInfoData buf, which is not
> > permitted.
>
> This will fail on every ANSI
Magnus Hagander <[EMAIL PROTECTED]> writes:
> From what I can tell, this is because the Assert() puts code (the do {}
> loop) *before* the declaration of StringInfoData buf, which is not
> permitted.
This will fail on every ANSI-C compiler, not just vc. Please fix.
regard
On Tue, Feb 13, 2007 at 04:29:16PM +0100, Magnus Hagander wrote:
> The latest set of XML changes (I think latest, at least fairly recent)
> broke the win32vc build with asserts enabled. The line:
> Assert(fully_escaped || !escape_period);
>
> From what I can tell, this is because the Assert(
The latest set of XML changes (I think latest, at least fairly recent)
broke the win32vc build with asserts enabled. The line:
Assert(fully_escaped || !escape_period);
>From what I can tell, this is because the Assert() puts code (the do {}
loop) *before* the declaration of StringInfoData
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 ""
without any particular name.
> Another neat feature would be if yo
Peter Eisentraut wrote:
tableforest = false gives you something like
...
tableforest = true gives you something like
...
...
...
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
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
data
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
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
Tino Wildenhain wrote:
> >
> > linda
> > 19
> > (0.9,6.1)
> > 100
> >
^
> >
> How would you express null in the values above?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadc
Peter Eisentraut schrieb:
The issue of XML export has been discussed a few times throughout
history. Right now you've got the HTML output in psql. A few
people have proposed "real" XML output formats in psql or elsewhere.
I dug out some old code today that implements what SQL/XML has to say
on
Pavel Stehule wrote:
> I thought about some special function. But why not? COPY is perfect
> for this task.
I don't understand what you are asking for. Please show an example.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)
Pavel Stehule wrote:
> If you integrate xml_export to core, you don't need string argument,
> which isn't too handy, but you can use COPY stmt aparat. I don't
> speak about enhancing stmt COPY.
Then what do you speak about?
I thought about some special function. But why not? COPY is perfect fo
Pavel Stehule wrote:
> If you integrate xml_export to core, you don't need string argument,
> which isn't too handy, but you can use COPY stmt aparat. I don't
> speak about enhancing stmt COPY.
Then what do you speak about?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
--
Hello
If you integrate xml_export to core, you don't need string argument, which
isn't too handy, but you can use COPY stmt aparat. I don't speak about
enhancing stmt COPY.
Regards
Pavel Stehule
p.s.
it's can be great if xmloutput will be independent on datestyle
root=# set datestyle TO Germ
On Sat, Feb 10, 2007 at 11:35:08AM -0800, Joshua D. Drake wrote:
> Peter Eisentraut wrote:
> > The issue of XML export has been discussed a few times throughout
> > history. Right now you've got the HTML output in psql. A few
> > people have proposed "real" XML output formats in psql or elsewhere
Andrew Dunstan wrote:
> How do you treat columns whose names are not legal XML names?
There are escape mechanisms in place. You can verify yourself how they
work using
select xmlelement(name "something unusual");
> I'm glad to see you treat NULL as an attribute - that's definitely
> the right
Peter Eisentraut wrote:
Below are examples of what it can do. I'm thinking about hosting this
on PgFoundry, but if the crowd thinks this should be somewhere else,
short of the moon, let me know.
How do you treat columns whose names are not legal XML names?
I'm glad to see you treat N
Peter Eisentraut wrote:
> The issue of XML export has been discussed a few times throughout
> history. Right now you've got the HTML output in psql. A few
> people have proposed "real" XML output formats in psql or elsewhere.
>
> I dug out some old code today that implements what SQL/XML has to
Joshua D. Drake wrote:
> Peter Eisentraut wrote:
>> The issue of XML export has been discussed a few times throughout
>> history. Right now you've got the HTML output in psql. A few
>> people have proposed "real" XML output formats in psql or elsewhere.
>>
>> I dug out some old code today that im
On Feb 10, 2007, at 2:35 PM, Joshua D. Drake wrote:
Peter Eisentraut wrote:
The issue of XML export has been discussed a few times throughout
history. Right now you've got the HTML output in psql. A few
people have proposed "real" XML output formats in psql or elsewhere.
I dug out some old
Peter Eisentraut wrote:
> The issue of XML export has been discussed a few times throughout
> history. Right now you've got the HTML output in psql. A few
> people have proposed "real" XML output formats in psql or elsewhere.
>
> I dug out some old code today that implements what SQL/XML has to
The issue of XML export has been discussed a few times throughout
history. Right now you've got the HTML output in psql. A few
people have proposed "real" XML output formats in psql or elsewhere.
I dug out some old code today that implements what SQL/XML has to say
on the matter and fitted the c
BTW,
Moreover, I would like xpath_string() which return
On 1/29/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
[...]
So, while I realize that I've been arguing for a lean core recently, I
want to propose that we add a small set of XPath support functions to
the core. This would come down to
Now that the xml type as per SQL:2003 is pretty much finished, one
starts to wonder about what useful things one might do with it. What
we have so far contains only functions to construct XML values from SQL
data, but there is nothing that you can do with the type at the moment
except look at
On Sun, 2007-01-21 at 08:36 +0100, Peter Eisentraut wrote:
> Tom Lane wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > Neil Conway wrote:
> > >> The regression.diffs are attached. Note that this reproduces
> > >> consistently, but only occurs if I use the "runtest" Makefile
> > >> targ
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Neil Conway wrote:
> >> The regression.diffs are attached. Note that this reproduces
> >> consistently, but only occurs if I use the "runtest" Makefile
> >> target (i.e. run the regression tests in serial mode); "make
> >> check" wo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> The regression.diffs are attached. Note that this reproduces
>> consistently, but only occurs if I use the "runtest" Makefile target
>> (i.e. run the regression tests in serial mode); "make check" works
>> fine, for example.
> Yo
Neil Conway wrote:
> The regression.diffs are attached. Note that this reproduces
> consistently, but only occurs if I use the "runtest" Makefile target
> (i.e. run the regression tests in serial mode); "make check" works
> fine, for example.
You need to re-initdb.
--
Peter Eisentraut
http://deve
$ make -C src/test/regress runtest
[ ... ]
test xml ... FAILED
test stats... ok
test tablespace ... ok
1 of 105 tests failed.
The regression.diffs are attached. Note that this reproduces
consistently, b
On Tue, Jan 16, 2007 at 06:41:56PM +0100, Florian G. Pflug wrote:
> If you do that, maybe it would be the easiest and least confusing thing
> to just _always_ represent an xml document in utf-8, ignoring the
> client_encoding
> entirely for xml.
You can't do that. The server needs to parse the i
Peter Eisentraut wrote:
I wrote:
We need to decide on how to handle encoding information embedded in
xml data that is passed through the client/server encoding
conversion.
Tangentially related, I'm currently experimenting with a setup that
stores all xml data in UTF-8 on the server, convertin
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Are we going to ensure that what we hand back to another client has
>> an appropriate encding decl? Or will we just remove it in all cases?
> We can't do the former, but the latter might be doable.
I think that in the case of
I wrote:
> We need to decide on how to handle encoding information embedded in
> xml data that is passed through the client/server encoding
> conversion.
Tangentially related, I'm currently experimenting with a setup that
stores all xml data in UTF-8 on the server, converting it back to the
serv
Andrew Dunstan wrote:
> We should error out on any explicit encoding that conflicts with the
> client encoding. I don't like the idea of just ignoring an explicit
> encoding decl.
That is an instance of the problem of figuring out which encoding names
are equivalent, which I believe we have settl
Peter Eisentraut wrote:
> Florian G. Pflug wrote:
>> Couldn't the server change the encoding declaration inside the xml to
>> the correct
>> one (the same as client_encoding) before returning the result?
>
> The data type output function doesn't know what the client encoding is
> or whether the dat
Florian G. Pflug wrote:
> Sorry, I don't get it - how does this work for text, then? It works
> there to dynamically recode the data from the database encoding to
> the client encoding before sending it off to the client, no?
Sure, but it doesn't change the text inside the datum.
--
Peter Eisentr
Peter Eisentraut wrote:
Florian G. Pflug wrote:
Couldn't the server change the encoding declaration inside the xml to
the correct
one (the same as client_encoding) before returning the result?
The data type output function doesn't know what the client encoding is
or whether the data will be s
Florian G. Pflug wrote:
> Couldn't the server change the encoding declaration inside the xml to
> the correct
> one (the same as client_encoding) before returning the result?
The data type output function doesn't know what the client encoding is
or whether the data will be shipped to the client a
Martijn van Oosterhout wrote:
> The only real alternative is to treat xml more like bytea than text
> (ie, treat the input as a stream of octets).
bytea isn't "treated" any different than other data types. You just
have to take care in the client that you escape every byte greater than
127. Th
Peter Eisentraut wrote:
Am Montag, 15. Januar 2007 17:33 schrieb Florian G. Pflug:
Would this mean that if the client_encoding is for example latin1, and I
retrieve an xml document uploaded by a client with client_encoding utf-8
(and thus having encoding="c" in the xml tag), that I would get a
d
1 - 100 of 151 matches
Mail list logo
