On 01/28/25 03:14, Jim Jones wrote:
> I'd say the difference is due to how the two systems handle the XML data
> type and unquoted identifiers in general, rather than a difference in
> the behaviour of the function itself.
I'd go further and say it's entirely down to how the two systems
handle un
Hi Robert
On 28.01.25 05:54, Robert Treat wrote:
> Was playing around with the patch and was thinking about this wording:
> "The xmldocument function returns the input argument
> unchanged... and is provided for compatibility."
>
> When I run an example similar to the db2 example you gave earlier
On Sat, Jan 25, 2025 at 6:45 AM Jim Jones wrote:
> On 25.01.25 11:50, Pavel Stehule wrote:
> > you still forces detoasting (inside PG_GETARG_XML_P)
>
>
> Ah, ok .. I overlooked it. You meant _DATUM instead of _XML_P
>
> Fixed in v8.
>
Was playing around with the patch and was thinking about this
Hi Chapman & Pavel
On 25.01.25 16:05, Pavel Stehule wrote:
>
>
> so 25. 1. 2025 v 15:10 odesílatel Chapman Flack napsal:
>
> On 01/25/25 02:16, Pavel Stehule wrote:
> > because the function does nothing, then it is useless to convert
> input to
> > XML and force detosting
> >
so 25. 1. 2025 v 15:10 odesílatel Chapman Flack napsal:
> On 01/25/25 02:16, Pavel Stehule wrote:
> > because the function does nothing, then it is useless to convert input to
> > XML and force detosting
> >
> > Maybe the body of the function should be just
> > ...
> > PG_RETURN_DATUM(PG_GETARG
On 01/25/25 02:16, Pavel Stehule wrote:
> because the function does nothing, then it is useless to convert input to
> XML and force detosting
>
> Maybe the body of the function should be just
> ...
> PG_RETURN_DATUM(PG_GETARG_DATUM(0));
That sort of motivated my question upthread about whether
so 25. 1. 2025 v 12:45 odesílatel Jim Jones
napsal:
>
> On 25.01.25 11:50, Pavel Stehule wrote:
> > you still forces detoasting (inside PG_GETARG_XML_P)
>
>
> Ah, ok .. I overlooked it. You meant _DATUM instead of _XML_P
>
> Fixed in v8.
>
now it is ok.
I'll mark this patch as ready for committ
On 25.01.25 11:50, Pavel Stehule wrote:
> you still forces detoasting (inside PG_GETARG_XML_P)
Ah, ok .. I overlooked it. You meant _DATUM instead of _XML_P
Fixed in v8.
Thanks!
Best, Jim
From 43cb30a6348a2e7b9911f8bb82e1ec8359b668f0 Mon Sep 17 00:00:00 2001
From: Jim Jones
Date: Fri, 24 Jan
so 25. 1. 2025 v 9:10 odesílatel Jim Jones
napsal:
>
> On 25.01.25 08:16, Pavel Stehule wrote:
> > because the function does nothing, then it is useless to convert input
> > to XML and force detosting
>
> Right. Fixed in v7 attached.
>
I don't see
+Datum
+xmldocument(PG_FUNCTION_ARGS)
+{
+#ifde
On 25.01.25 08:16, Pavel Stehule wrote:
> because the function does nothing, then it is useless to convert input
> to XML and force detosting
Right. Fixed in v7 attached.
Thanks
Best, Jim
From f4dc90994fc42879c7ab522bd9a03032be9a936c Mon Sep 17 00:00:00 2001
From: Jim Jones
Date: Fri, 24 Jan 2
pá 24. 1. 2025 v 23:11 odesílatel Jim Jones
napsal:
>
> On 24.01.25 22:01, Chapman Flack wrote:
> > It seems to me the key connection there is that the ISO SQL standard
> > defines XMLDOCUMENT by equivalence to what `document { $expr }` means
> > in the W3 XML Query standard.
>
>
> It seems I mis
On 24.01.25 22:01, Chapman Flack wrote:
> It seems to me the key connection there is that the ISO SQL standard
> defines XMLDOCUMENT by equivalence to what `document { $expr }` means
> in the W3 XML Query standard.
It seems I missed one sentence. My bad.
Next try... :)
The xmldocument functio
On 01/24/25 14:59, Jim Jones wrote:
> In the XML Query standard, a "document node" represents a relaxed
> version of an XML document structure. This corresponds to what
> PostgreSQL's single XML type allows, meaning that any valid non-null
> PostgreSQL XML value can be returned unchanged. Other sys
Hi
On 24.01.25 17:18, Chapman Flack wrote:
> Or even: ... An XML Query "document node" is a relaxed version
> of XML document structure that corresponds exactly to what
> PostgreSQL's one XML type is already allowed to contain, so
> any non-null PostgreSQL XML value can be returned unchanged.
> Mo
On 01/24/25 10:49, Chapman Flack wrote:
> The SQL-standard `XMLDOCUMENT` function applied to an XML value
> /expr/ has effects equivalent to the XML Query expression
> `document { /expr/ }`, specified to replace any document nodes
> in the input with their children and wrap the whole result in one
On 01/24/25 08:48, Jim Jones wrote:
> In the SQL/XML specification, the XMLDocument (X030) function is
> designed to return a document node from a given XML value expression.
Maybe we can take advantage of the way that specifications usually
don't mandate an implementation, but only results equiva
pá 24. 1. 2025 v 14:48 odesílatel Jim Jones
napsal:
>
> On 24.01.25 13:48, Pavel Stehule wrote:
> > Lot of users use XML functions without XMLDOCUMENT now. The doc should to
> > help with a reply to question where and when I need (I can) use this
> > function. This should
> > be in context of Pos
On 24.01.25 13:48, Pavel Stehule wrote:
> Lot of users use XML functions without XMLDOCUMENT now. The doc should to
> help with a reply to question where and when I need (I can) use this
> function. This should
> be in context of Postgres where every XML expr returns XML value, so
> sentence
> cr
pá 24. 1. 2025 v 13:21 odesílatel Jim Jones
napsal:
>
> On 24.01.25 12:31, Pavel Stehule wrote:
> > I don't know what it means - `function returns a document node` in the
> > context of Postgres implementation of XML.
> > I miss the information so it returns an input argument without
> > changing
On 24.01.25 12:31, Pavel Stehule wrote:
> I don't know what it means - `function returns a document node` in the
> context of Postgres implementation of XML.
> I miss the information so it returns an input argument without
> changing anything, because in a system, where XML expression
> holds a c
pá 24. 1. 2025 v 9:12 odesílatel Jim Jones
napsal:
> Hi
>
> On 24.01.25 07:28, Pavel Stehule wrote:
> > I think documentation should be strongly enhanced. This is probably
> > the hardest part of this patch - explain well what this function does
> > and what it doesn't.
>
> You mean something lik
Hi
On 24.01.25 07:28, Pavel Stehule wrote:
> I think documentation should be strongly enhanced. This is probably
> the hardest part of this patch - explain well what this function does
> and what it doesn't.
You mean something like this? Or perhaps something more technical?
The xmldocument funct
čt 23. 1. 2025 v 16:06 odesílatel Jim Jones
napsal:
> Hi
>
> On 23.01.25 07:50, Pavel Stehule wrote:
> > I think so in this form (just forward input to output) I have no
> > objection.
> >
> > There is a benefit with a) possible zero work with migration from db2,
> > b) nobody needs to repeat a w
Hi
čt 23. 1. 2025 v 16:06 odesílatel Jim Jones
napsal:
> Hi
>
> On 23.01.25 07:50, Pavel Stehule wrote:
> > I think so in this form (just forward input to output) I have no
> > objection.
> >
> > There is a benefit with a) possible zero work with migration from db2,
> > b) nobody needs to repeat
Hi
On 23.01.25 07:50, Pavel Stehule wrote:
> I think so in this form (just forward input to output) I have no
> objection.
>
> There is a benefit with a) possible zero work with migration from db2,
> b) nobody needs to repeat a work which is a correct implementation of
> XMLDOCUMENT function.
>
>
čt 23. 1. 2025 v 0:55 odesílatel Jim Jones
napsal:
> Hi Chapman & Robert
>
> Many thanks for the input
>
> On 22.01.25 22:35, Chapman Flack wrote:
> > On 01/22/25 13:41, Robert Treat wrote:
> >> So even if we are following the spec (which I think technically we may
> >> not be),
> > There are def
Hi Chapman & Robert
Many thanks for the input
On 22.01.25 22:35, Chapman Flack wrote:
> On 01/22/25 13:41, Robert Treat wrote:
>> So even if we are following the spec (which I think technically we may
>> not be),
> There are definite ways in which we're not following the SQL/XML spec,
> which we
On 01/22/25 13:41, Robert Treat wrote:
> So even if we are following the spec (which I think technically we may
> not be),
There are definite ways in which we're not following the SQL/XML spec,
which we document in an appendix[1]. The one that matters here is that
we just have a single XML type in
On Tue, Jan 21, 2025 at 6:36 PM Jim Jones wrote:
> On 21.01.25 23:45, Robert Treat wrote:
> > Is there some concrete use case you have seen that this would help
> > with? Not objecting to adding it, but you've mentioned this migration
> > idea twice but it seems to me this doesn't conform with exi
On 21.01.25 23:45, Robert Treat wrote:
> Is there some concrete use case you have seen that this would help
> with? Not objecting to adding it, but you've mentioned this migration
> idea twice but it seems to me this doesn't conform with existing
> implementations, and I don't see much benefit in
On Tue, Jan 21, 2025 at 5:58 AM Jim Jones wrote:
> On 20.01.25 23:21, Chapman Flack wrote:
> > Therefore I'm thinking that, given the specifics of our XML support,
> > a fully conformant and efficient XMLDOCUMENT could be implemented
> > just by returning its XML argument.
>
>
> After your explana
On 20.01.25 23:21, Chapman Flack wrote:
> Therefore I'm thinking that, given the specifics of our XML support,
> a fully conformant and efficient XMLDOCUMENT could be implemented
> just by returning its XML argument.
After your explanation, I tend to agree.
v3, attached, incorporates these chan
On 01/20/25 14:56, Jim Jones wrote:
> If I understand correctly, the compliant approach would be to always
> treat the input expression as CONTENT:
>
> |PG_RETURN_XML_P(xmlparse((text *) data, XMLOPTION_DOCUMENT, true));|
>
> Is that right?"
Did you mean XMLOPTION_CONTENT?
I think that would be
On 2025-01-20 Mo 2:09 PM, Chapman Flack wrote:
Long story short, an XMLDOCUMENT constructor that enforced having
a single root element would be nonconformant.
What an (expletive deleted) mess. I'm glad someone is on top of it.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprise
Hi Chap,
Thanks for the thorough explanation!
On 20.01.25 20:09, Chapman Flack wrote:
>> PostgreSQL does not support the RETURNING SEQUENCE or RETURNING CONTENT
>> clauses explicitly. Instead, it implicitly uses RETURNING CONTENT[2] in
>> functions that require it. Since RETURNING CONTENT implie
On 01/20/25 06:02, Jim Jones wrote:
> The DB2 "Document node constructors" might provide some insights into
> its behavior regarding well-formed XML documents [1]:
>
> "No validation is performed on the constructed document node. The XQuery
> document node constructor does not enforce the XML 1.0
On 16.01.25 08:21, Jim Jones wrote:
> On 16.01.25 07:11, Pavel Stehule wrote:
>> It is better.
> v2 attached updates the documentation.
>> My note was related to a very different description of this
>> functionality in DB2. So if you propose this function for better
>> compatibility (and this fun
On 16.01.25 07:11, Pavel Stehule wrote:
> It is better.
v2 attached updates the documentation.
>
> My note was related to a very different description of this
> functionality in DB2. So if you propose this function for better
> compatibility (and this function is implemented only by db2), it is
>
st 15. 1. 2025 v 22:05 odesílatel Jim Jones
napsal:
> Hi Pavel
>
> On 14.01.25 09:14, Pavel Stehule wrote:
> > I did some research and the design of this document is different
> >
> > 1. Oracle doesn't support this
> > 2. DB2 has different implementations for z/OS (variadic) and for unix
> > (non
Hi Pavel
On 14.01.25 09:14, Pavel Stehule wrote:
> I did some research and the design of this document is different
>
> 1. Oracle doesn't support this
> 2. DB2 has different implementations for z/OS (variadic) and for unix
> (nonvariadic)
> 3. looks so db2 allows some concatenation of xml content
Hi
út 14. 1. 2025 v 8:11 odesílatel Jim Jones
napsal:
> Hi,
>
> I'd like to propose the implementation of XMLDocument (SQL/XML X030).It
> basically returns an XML document from a given XML expression, e.g.
>
> SELECT
>xmldocument(
> xmlelement(NAME foo,
>xmlattributes(42 AS att)
Hi Andrew
On 10.12.24 14:59, Andrew Dunstan wrote:
> LGTM at a first glance.
>
>
> Please add this to the next CommitFest if you haven't done already.
Thanks!
This is the CF entry: https://commitfest.postgresql.org/51/5431/
Best, Jim
On 2024-12-10 Tu 2:48 AM, Jim Jones wrote:
On 04.12.24 17:18, Jim Jones wrote:
I'd like to propose the implementation of XMLDocument (SQL/XML X030).
It basically returns an XML document from a given XML expression, e.g.
SELECT
xmldocument(
xmlelement(NAME foo,
xmlattributes(42
On 04.12.24 17:18, Jim Jones wrote:
> I'd like to propose the implementation of XMLDocument (SQL/XML X030).
> It basically returns an XML document from a given XML expression, e.g.
>
> SELECT
> xmldocument(
> xmlelement(NAME foo,
> xmlattributes(42 AS att),
> xmlelement(NAME bar,
44 matches
Mail list logo
