Re: Native XML
От | Bruce Momjian |
---|---|
Тема | Re: Native XML |
Дата | |
Msg-id | 201103091811.p29IBhu15113@momjian.us обсуждение исходный текст |
Ответ на | Re: Native XML (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Native XML
Re: Native XML |
Список | pgsql-hackers |
Robert Haas wrote: > On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane <tgl@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 essentially duplicate functionality isn't pleasing at all. > > The real issue here is whether we want to store XML as text (as we do > now) or as some predigested form which would make "output the whole > thing" slower but speed up things like xpath lookups. We had the same > issue with JSON, and due to the uncertainty about which way to go with > it we ended up integrating nothing into core at all. It's really not > clear that there is one way of doing this that is right for all use > cases. 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 data > using other xpath expressions, you would probably prefer the other > representation. Someone should measure how much overhead the indexing of xml values might have. If it is minor, we might be OK with only an indexed xml type. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: