SQL/XML publishing function experimental patch II

On Wed, Sep 28, 2005 at 04:30:54PM +0200, Pavel Stehule wrote:

Hello

base type changed to text, better registration xmlagg function

Interesting. The SGML docs appear to be machine-generated stubs.
Could you point to a reference for them so they can be filled in?

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

On Wed, Sep 28, 2005 at 04:30:54PM +0200, Pavel Stehule wrote:

Hello

base type changed to text, better registration xmlagg function

Regards Pavel Stehule

Now with some slightly improved documentation, works vs. CVS tip as of
this writing.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

This has been saved for the 8.2 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

David Fetter wrote:

On Wed, Sep 28, 2005 at 04:30:54PM +0200, Pavel Stehule wrote:

Hello

base type changed to text, better registration xmlagg function

Regards Pavel Stehule

Now with some slightly improved documentation, works vs. CVS tip as of
this writing.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Do we want this XML patch in the backend? It needs syntax support so I
don't see how it could be done in /contrib. Attached.

---------------------------------------------------------------------------

David Fetter wrote:

On Wed, Sep 28, 2005 at 04:30:54PM +0200, Pavel Stehule wrote:

Hello

base type changed to text, better registration xmlagg function

Regards Pavel Stehule

Now with some slightly improved documentation, works vs. CVS tip as of
this writing.

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Do we want this XML patch in the backend? It needs syntax support so I
don't see how it could be done in /contrib. Attached.

I think this could easily be done as an external module if it didn't
insist on random additions to the function-call syntax. AFAICS there
isn't anything there that couldn't be done without that.

regards, tom lane

Tom Lane wrote:

I think this could easily be done as an external module if it didn't
insist on random additions to the function-call syntax. AFAICS there
isn't anything there that couldn't be done without that.

This is part of the SQL standard.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Tom Lane wrote:

I think this could easily be done as an external module if it didn't
insist on random additions to the function-call syntax. AFAICS there
isn't anything there that couldn't be done without that.

This is part of the SQL standard.

Ah, I suspected that might be true.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Peter Eisentraut <peter_e@gmx.net> writes:

This is part of the SQL standard.

[ shrug ] There is a *boatload* of new stuff in SQL2003, most of which
we probably won't ever implement. The foundation alone has enough new
cruft to keep us busy for years ... never mind stuff that shows up only
in Part 14.

Basically, SQL2003 is way too big for the argument "it's in the spec"
to be an automatic trump card for putting features into core PG.
We have to think about distribution size and maintainability versus
the usefulness of specific features.

If there were a serious amount of demand for the SQL2003 XML features
then I wouldn't be averse to putting them in, but right now it looks
like bloat with little redeeming social value. Who other than the
submitter has asked for this? I don't even see "XML" listed in TODO.

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

This is part of the SQL standard.

[ shrug ] There is a *boatload* of new stuff in SQL2003, most of which
we probably won't ever implement. The foundation alone has enough new
cruft to keep us busy for years ... never mind stuff that shows up only
in Part 14.

Basically, SQL2003 is way too big for the argument "it's in the spec"
to be an automatic trump card for putting features into core PG.
We have to think about distribution size and maintainability versus
the usefulness of specific features.

If there were a serious amount of demand for the SQL2003 XML features
then I wouldn't be averse to putting them in, but right now it looks
like bloat with little redeeming social value. Who other than the
submitter has asked for this? I don't even see "XML" listed in TODO.

Well, we have been pushing XML out of the database into side projects,
which I think is the way to go until we have an XML-standard export
format. With this one, I don't see how we can do it externally and meet
the spec. I would like to see an outline of what XML things we support
and what we don't. Is this XML patch a major missing thing? No idea.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Do we want this XML patch in the backend? It needs syntax support so I
don't see how it could be done in /contrib. Attached.

I think this could easily be done as an external module if it didn't
insist on random additions to the function-call syntax. AFAICS there
isn't anything there that couldn't be done without that.

No, I am sorry, it's cannot be external module. Or cannot be without losting
functionality and elegance of SQL/XML. It's really depend on parser. People
which generate XML from database used it. But not now, because PostgreSQL
don't support it. But it's the moust faster way for generating XML files,
10x faster then PHP or Perl. Please look again on this patch. I am not sure
about solution without ANSI compatibility.

Regards
Pavel Stehule

_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/

Well, we have been pushing XML out of the database into side projects,
which I think is the way to go until we have an XML-standard export
format. With this one, I don't see how we can do it externally and meet
the spec. I would like to see an outline of what XML things we support
and what we don't. Is this XML patch a major missing thing? No idea.

We don't need export XML. I need XML directly from database. I understand so
this patch add some rows to server, but it's save thousands lines on client
sides. Every AJAX or .NET scripts can use it.

Regards
Pavel Stehule

_________________________________________________________________
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/

Hello

If there were a serious amount of demand for the SQL2003 XML features
then I wouldn't be averse to putting them in, but right now it looks
like bloat with little redeeming social value. Who other than the
submitter has asked for this? I don't even see "XML" listed in TODO.

1. integrating SQL/XML into engine put some possibilities for faster and
eficient generating XML file. Is important for generating large XML files.
XML has recursive sturucture and normal (classic functions) interface isn't
eficient, because it's need more XML->text conversions. Inside parser I know
if I inside recursion or outside.

2. Some people use my patch. Without my patch there will be more request for
it.

Best regards
Pavel Stehule

_________________________________________________________________
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/

Pavel Stehule wrote:

Hello

If there were a serious amount of demand for the SQL2003 XML features
then I wouldn't be averse to putting them in, but right now it looks
like bloat with little redeeming social value. Who other than the
submitter has asked for this? I don't even see "XML" listed in TODO.

1. integrating SQL/XML into engine put some possibilities for faster and
eficient generating XML file. Is important for generating large XML files.
XML has recursive sturucture and normal (classic functions) interface isn't
eficient, because it's need more XML->text conversions. Inside parser I know
if I inside recursion or outside.

2. Some people use my patch. Without my patch there will be more request for
it.

OK, got it. One thing I would like is a summary of what we support
directly, in /contrib, and externally. I would like something that can
be eventually put in our documentation, because right now, people say,
"I need XML", and they are not clear about exactly what they need.
Things like:

storing xml
searching xml
exporting xml
building xml structures
etc.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:

If there were a serious amount of demand for the SQL2003 XML features
then I wouldn't be averse to putting them in, but right now it looks
like bloat with little redeeming social value. Who other than the
submitter has asked for this? I don't even see "XML" listed in TODO.

There have been inquiries about some kind of XML support every few weeks
for years now. Clearly, we need to sort out what that really means.
I'm preparing a session about that for the Toronto summit.

There is now a Summer of Code project for creating an XML data type,
which should be integrated with this work and the xpath stuff in
contrib. Plus, there were a few rejected projects about creating
special index support for XML.

Whether or not this part is really useful I can't judge, but it's part
of an overall system.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:

There have been inquiries about some kind of XML support every few weeks
for years now. Clearly, we need to sort out what that really means.

Agreed. We need a road map of some sort.

I'm preparing a session about that for the Toronto summit.

Looking forward to it...

regards, tom lane

I'll prepare some classification of differend kinds of XML support,
including a brief overview for oracle, sql server and db2 (I'm a
person who works on that SoC project)

As for Pavel's patch, I think it's pretty complete piece of several
SQL/XML functions and could be usefull for people (e.g for me).

But it isn't fulll 'XML support' yet. On the road to XML type I see
more grammar hacks (if standard compliance should be established) -
for example, one of possible xml-column declarations is '...col1
XML(SEQUENCE (UNTYPED))...', what breaks postgres' syntax for types
descriptors, if I'm not mistaken..

Yes, standard is bloated and there is no dbms that supports part 14
entirely (e.g., oracle doesn't accept xquery sequnces for xml type, ms
calls its type 'xmltype' and doesn't support sql/xml functions), but
it contains some collection of experience. Many people want to store
xml and to work with it - so some work should take place. Another
point: no open-source dbms has good xml support, so... Anyway, it
would be attractive feature (speaking about marketing - look at the
db2 v.9 'viper' description: xml, xml, xml...)

On 6/15/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

There have been inquiries about some kind of XML support every few weeks
for years now. Clearly, we need to sort out what that really means.

Agreed. We need a road map of some sort.

I'm preparing a session about that for the Toronto summit.

Looking forward to it...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

--
Best regards,
Nikolay

I am still waiting for some documentation on what XML support we have,
and what we need. We can't decide on this patch until we have that.

---------------------------------------------------------------------------

Nikolay Samokhvalov wrote:

I'll prepare some classification of differend kinds of XML support,
including a brief overview for oracle, sql server and db2 (I'm a
person who works on that SoC project)

As for Pavel's patch, I think it's pretty complete piece of several
SQL/XML functions and could be usefull for people (e.g for me).

But it isn't fulll 'XML support' yet. On the road to XML type I see
more grammar hacks (if standard compliance should be established) -
for example, one of possible xml-column declarations is '...col1
XML(SEQUENCE (UNTYPED))...', what breaks postgres' syntax for types
descriptors, if I'm not mistaken..

Yes, standard is bloated and there is no dbms that supports part 14
entirely (e.g., oracle doesn't accept xquery sequnces for xml type, ms
calls its type 'xmltype' and doesn't support sql/xml functions), but
it contains some collection of experience. Many people want to store
xml and to work with it - so some work should take place. Another
point: no open-source dbms has good xml support, so... Anyway, it
would be attractive feature (speaking about marketing - look at the
db2 v.9 'viper' description: xml, xml, xml...)

On 6/15/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

There have been inquiries about some kind of XML support every few weeks
for years now. Clearly, we need to sort out what that really means.

Agreed. We need a road map of some sort.

I'm preparing a session about that for the Toronto summit.

Looking forward to it...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

--
Best regards,
Nikolay

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On 8/22/06, Bruce Momjian <bruce@momjian.us> wrote:

I am still waiting for some documentation on what XML support we have,
and what we need. We can't decide on this patch until we have that.

Here is my thoughts:
http://nikolay.samokhvalov.com/2006/08/23/xml-and-relational/
(maybe too much words - sorry for it - but classification is very
simple and then I give some simple but important examples; if you them
too boring, read the two comments and the end).

As for that patch itself, I can say two things:
1. It's really useful but can be considered only as the first step
to XML type support; I personally would be very happy if it will be
included in 8.2 not by default, but with "--with-xml" configure option
(the patch changes the grammar... is it possible to provide the user
with capabilities to define during configuration process what parts of
gram.y will be turned on?)
2. It has some problems such as following:
a) "SELECT XMLELEMENT(NAME "A<!--111", 222);" produces invalid XML
(the substring "--" cannot be used in element names, and even as text
value of XML elements). In other words, patch uses ColCabel to define
XML element names, which is not correct (needs additional narrowing);
b) subqueries inside some constructions are not possible, e.g.:
"SELECT XMLCONCAT((SELECT XMLELEMENT(NAME aaa, 111)), XMLELEMENT(NAME
bbb, 222));" doesn't work (only straight list of xmlexpr can be
accepted). Another simple example of this issue is XMLCONCAT of NULLs
(NULL is valid XML value according to SQL/XML:200{3,6});
c) XMLPI should have "NAME" keyword before the first argument
(similar to XMLELEMENT), according to SQL/XML:2003.

Since I use this patch in my work on SoC's "initial support of XML
type" (I'll describe results and provide the code in the separate
messages later), I've improved some of issues as long as typos - such
as "<-- ... -->" instead of "<!-- ... -->" in XMLCOMMENT definition,
code style cleanup, etc. If you decide to include Pavel's patch to
8.2, I'll be glad to create the slightly improved version of his
patch.

I plan to continue discussing the theme of XML-enabled databases and
discuss abilities that Postgres has in this area.

Hope, this will help. Please, if you see that I am wrong somewhere -
let me know / let's discuss it.

--
Best regards,
Nikolay