On Wed, Mar 9, 2011 at 7:03 PM, Josh Berkus j...@agliodbs.com wrote:
Then I think the answer is that we need both data types. One for
text-XML and one for binary-XML.
That's what I think, too. I'm not sure whether we want both of them
in core, but I think the binary-XML one would, at a
Robert Haas wrote:
On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, in principle we could allow them to work on both, just the same
way that (for instance) + is a standardized operator but works on more
than one datatype. ?But I agree that the prospect of two
On Wed, Mar 9, 2011 at 1:11 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, in principle we could allow them to work on both, just the same
way that (for instance) + is a standardized operator but works
On 2011-03-09 19:30, Robert Haas wrote:
On Wed, Mar 9, 2011 at 1:11 PM, Bruce Momjianbr...@momjian.us wrote:
Robert Haas wrote:
On Mon, Feb 28, 2011 at 10:30 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Well, in principle we could allow them to work on both, just the same
way that (for instance) +
On 03/09/2011 08:21 PM, Yeb Havinga wrote:
On 2011-03-09 19:30, Robert Haas wrote:
On Wed, Mar 9, 2011 at 1:11 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, in principle we could
On 3/9/11 10:11 AM, Bruce Momjian wrote:
If you are storing xml in an xml column just to get it
validated, and doing no processing in the DB, then you'd probably
prefer our current representation. If you want to build functional
indexes on xpath expressions, and then run queries that extract
2011/3/1 Andrew Dunstan and...@dunslane.net:
I think hierarchical data really only scratches the surface of the problem.
It would be nice to be able to specify all sorts of context for searches:
* foo after bar
* foo near bar
* foo and bar in the same paragraph
* foo as a
On Mon, Feb 28, 2011 at 6:54 PM, Andrew Dunstan and...@dunslane.net wrote:
There seems to be an almost universal assumption that storing XML in its
native form (i.e. a text stream) is going to produce inefficient results.
Maybe it will, but I think it needs to be fairly convincingly
On 03/01/2011 08:16 AM, Robert Haas wrote:
On Mon, Feb 28, 2011 at 6:54 PM, Andrew Dunstanand...@dunslane.net wrote:
There seems to be an almost universal assumption that storing XML in its
native form (i.e. a text stream) is going to produce inefficient results.
Maybe it will, but I think
Andrew Dunstan and...@dunslane.net wrote:
On 02/28/2011 05:28 PM, Kevin Grittner wrote:
Antonantonin.hou...@gmail.com wrote:
it was actually the focal point of my considerations: whether to
store plain text or 'something else'.
There seems to be an almost universal assumption that storing
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I apparently didn't express myself very well, since you seem to have
*completely* missed my point. I know we can do tsearch2 searches
against XML, or JSON, or YAML, or (insert next week's new favorite
format here). What we can't currently do
On 03/01/2011 02:15 PM, Kevin Grittner wrote:
Given that there were similar issues for other hierarchical data
types, perhaps we need something similar to tsvector, but for
hierarchical data. The extra layer of abstraction might not cost
much when used for XML compared to the possible
On 02/27/2011 11:57 PM, Peter Eisentraut wrote:
On sön, 2011-02-27 at 10:45 -0500, Tom Lane wrote:
Hmm, so this doesn't rely on libxml2 at all? Given the amount of pain
that library has caused us, getting out from under it seems like a
mighty attractive idea.
This doesn't replace
On 02/28/2011 04:25 AM, Anton wrote:
On 02/27/2011 11:57 PM, Peter Eisentraut wrote:
On sön, 2011-02-27 at 10:45 -0500, Tom Lane wrote:
Hmm, so this doesn't rely on libxml2 at all? Given the amount of pain
that library has caused us, getting out from under it seems like a
mighty attractive
Andrew Dunstan and...@dunslane.net writes:
On 02/28/2011 04:25 AM, Anton wrote:
A question is of course, if potential new implementation must
necessarily replace the existing one, immediately or at all. What I
published is implemented as a new data type and thus pg_type.h and
pg_proc.h are
On Sun, Feb 27, 2011 at 10:20 PM, Andrew Dunstan and...@dunslane.net wrote:
No, I think the xpath implementation is from libxml2. But in any case, I
think the problem is in the whole design of the xpath_table function, and
not in the library used for running the xpath queries. i.e it's our
On 02/28/2011 10:30 AM, Tom Lane wrote:
The single most pressing problem we've got with XML right now
is the poor state of the XPath extensions in contrib/xml2. If we don't
see a meaningful step forward in that area, a new implementation of the
xml datatype isn't likely to win acceptance.
Andrew Dunstan and...@dunslane.net writes:
xpath_table is severely broken by design IMNSHO. We need a new design,
but I'm reluctant to work on that until someone does LATERAL, because a
replacement would be much nicer to design with it than without it.
Well, maybe I'm missing something, but
On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, in principle we could allow them to work on both, just the same
way that (for instance) + is a standardized operator but works on more
than one datatype. But I agree that the prospect of two parallel types
with
On 02/28/2011 10:51 AM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
xpath_table is severely broken by design IMNSHO. We need a new design,
but I'm reluctant to work on that until someone does LATERAL, because a
replacement would be much nicer to design with it than without it.
On 02/28/2011 05:23 PM, Robert Haas wrote:
On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, in principle we could allow them to work on both, just the same
way that (for instance) + is a standardized operator but works on more
than one datatype. But I agree that
Anton antonin.hou...@gmail.com wrote:
it was actually the focal point of my considerations: whether to
store plain text or 'something else'.
Given that there were similar issues for other hierarchical data
types, perhaps we need something similar to tsvector, but for
hierarchical data. The
On 02/28/2011 05:28 PM, Kevin Grittner wrote:
Antonantonin.hou...@gmail.com wrote:
it was actually the focal point of my considerations: whether to
store plain text or 'something else'.
There seems to be an almost universal assumption that storing XML in its
native form (i.e. a text
Anton antonin.hou...@gmail.com writes:
I've been playing with 'native XML' for a while and now wondering if
further development of such a feature makes sense for Postgres.
...
Unlike 'libxml2', the parser uses palloc()/pfree(). The output format is
independent from any 3rd party code.
Hmm,
On 02/27/2011 10:45 AM, Tom Lane wrote:
Antonantonin.hou...@gmail.com writes:
I've been playing with 'native XML' for a while and now wondering if
further development of such a feature makes sense for Postgres.
...
Unlike 'libxml2', the parser uses palloc()/pfree(). The output format is
Andrew Dunstan and...@dunslane.net writes:
On 02/27/2011 10:45 AM, Tom Lane wrote:
Hmm, so this doesn't rely on libxml2 at all? Given the amount of pain
that library has caused us, getting out from under it seems like a
mighty attractive idea. How big a chunk of code do you think it'd be
by
On Feb 27, 2011, at 11:23 AM, Tom Lane wrote:
Well, that's why I asked --- if it's going to be a huge chunk of code,
then I agree this is the wrong path to pursue. However, I do feel that
libxml pretty well sucks, so if we could replace it with a relatively
small amount of code, that might
David E. Wheeler da...@kineticode.com writes:
On Feb 27, 2011, at 11:23 AM, Tom Lane wrote:
No, because the xpath stuff is fundamentally broken, and nobody seems to
know how to make libxslt do what we actually need. See the open bugs
on the TODO list.
XPath is broken? I use it heavily in
On 27/02/11 19:37, David E. Wheeler wrote:
On Feb 27, 2011, at 11:23 AM, Tom Lane wrote:
Well, that's why I asked --- if it's going to be a huge chunk of code,
then I agree this is the wrong path to pursue. However, I do feel that
libxml pretty well sucks, so if we could replace it with a
On Feb 27, 2011, at 11:43 AM, Tom Lane wrote:
XPath is broken? I use it heavily in the Perl module Test::XPath and now, in
PostgreSQL, with my explanation extension.
Well, if you're only using cases that work, you don't need to worry.
Okay then.
David
--
Sent via pgsql-hackers mailing
Mike Fowler m...@mlfowler.com writes:
I don't believe that XPath is fundamentally broken, but I think Tom
may have meant xslt. When reviewing a recent patch to xml2/xslt I found
a few bugs in the way were using libxslt, as well as a bug in the
library itself (see
Sorry for resending, I forgot to add 'pgsql-hackers' to CC.
Original Message
Subject:Re: [HACKERS] Native XML
Date: Sun, 27 Feb 2011 23:18:03 +0100
From: Anton antonin.hou...@gmail.com
To: Tom Lane t...@sss.pgh.pa.us
On 02/27/2011 04:45 PM, Tom Lane wrote
On sön, 2011-02-27 at 10:45 -0500, Tom Lane wrote:
Hmm, so this doesn't rely on libxml2 at all? Given the amount of pain
that library has caused us, getting out from under it seems like a
mighty attractive idea.
This doesn't replace the existing xml functionality, so it won't help
getting rid
On 02/27/2011 03:06 PM, Tom Lane wrote:
Mike Fowlerm...@mlfowler.com writes:
I don't believe that XPath is fundamentally broken, but I think Tom
may have meant xslt. When reviewing a recent patch to xml2/xslt I found
a few bugs in the way were using libxslt, as well as a bug in the
library
Andrew Dunstan and...@dunslane.net writes:
On 02/27/2011 03:06 PM, Tom Lane wrote:
The case that I don't think we have any idea how to solve is
http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php
I'd forgotten about this. But as ugly as it is, I don't think it's
libxml2's
On 02/27/2011 10:07 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 02/27/2011 03:06 PM, Tom Lane wrote:
The case that I don't think we have any idea how to solve is
http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php
I'd forgotten about this. But as ugly as
Hello,
I've been playing with 'native XML' for a while and now wondering if
further development of such a feature makes sense for Postgres.
(By not having brought this up earlier I'm taking the chance that the
effort will be wasted, but that's not something you should worry about.)
The code is
On 2/26/11 3:40 PM, Anton wrote:
I've been playing with 'native XML' for a while and now wondering if
further development of such a feature makes sense for Postgres.
(By not having brought this up earlier I'm taking the chance that the
effort will be wasted, but that's not something you should
38 matches
Mail list logo
