Thread: [GENERAL] xmlelement AND timestamps.

[GENERAL] xmlelement AND timestamps.

From
Lynn Dobbs
Date:
I just migrated from 9.2.4 to 9.6.1 and had several user created
functions fail.

Recreating the failure with "SELECT xmlelement(name foo,
'infinity'::timestamp)
ERROR: timestamp out of range
DETAIL: XML does not support infinite timestamp values.

I don't find anything in the documentation that explains this.  I
consider this a regression.

I have many tables that have a "starting" and "ending" timestamp that
default to "-infinity"
and "infinity" respectively.   Any function I have that outputs xml
containing those columns
have to have those values cast to text.

Lynn Dobbs
--
Chief Technical Office
CreditLink Corporation
858-496-1000 x 103



Re: [GENERAL] xmlelement AND timestamps.

From
Adrian Klaver
Date:
On 02/13/2017 02:56 PM, Lynn Dobbs wrote:
> I just migrated from 9.2.4 to 9.6.1 and had several user created
> functions fail.
>
> Recreating the failure with "SELECT xmlelement(name foo,
> 'infinity'::timestamp)
> ERROR: timestamp out of range
> DETAIL: XML does not support infinite timestamp values.
>
> I don't find anything in the documentation that explains this.  I
> consider this a regression.

All I could find was this thread from 2009:

https://www.postgresql.org/message-id/41F26B729B014C3E8F20F5B7%40teje

which indicated it was fixed at that time.



>
> I have many tables that have a "starting" and "ending" timestamp that
> default to "-infinity"
> and "infinity" respectively.   Any function I have that outputs xml
> containing those columns
> have to have those values cast to text.
>
> Lynn Dobbs
> --
> Chief Technical Office
> CreditLink Corporation
> 858-496-1000 x 103
>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com


Re: [GENERAL] xmlelement AND timestamps.

From
"David G. Johnston"
Date:
On Mon, Feb 13, 2017 at 6:36 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 02/13/2017 02:56 PM, Lynn Dobbs wrote:
I just migrated from 9.2.4 to 9.6.1 and had several user created
functions fail.

Recreating the failure with "SELECT xmlelement(name foo,
'infinity'::timestamp)
ERROR: timestamp out of range
DETAIL: XML does not support infinite timestamp values.

I don't find anything in the documentation that explains this.  I
consider this a regression.

All I could find was this thread from 2009:

https://www.postgresql.org/message-id/41F26B729B014C3E8F20F5B7%40teje

which indicated it was fixed at that time.

​Actually, the cause of said commit (circa 2009) is that xmlelements were failing but xmlattributes were not​...which makes me wonder how a 9.2 era release (circa 2012) supposedly worked with the submitted expression.

The basic answer is that the XML data type is defined by standard and we attempt to conform to the standard.  In order to do so we must disallow infinite timestamps even though we accept them in SQL.

I just tested the OP query on 9.0.x and 9.4.x and get the same error on both.

There'd be a bit more sympathy if the OP were complaining about a patch release changing behavior - bug fix or not - but since the complaint involves going from 9.2 to 9.6 on its face this is an allowed behavior change regardless of the history.

However, feel free to make a straight argument for accepting infinite timestamps and thus go above-and-beyond the relevant standards.  Personally this seems like a not-so-useful restriction on our implementation.  Let the user decide whether they want to deviate from the standard and risk cross-system incompatibilities.  XML itself is textual and we don't have any internal support for DTD or Schema as it is so I'm not sure what material benefit we gain by restraining ourselves here.

David J.

Re: [GENERAL] xmlelement AND timestamps.

From
Tom Lane
Date:
Lynn Dobbs <lynn.dobbs@creditlink.com> writes:
> I just migrated from 9.2.4 to 9.6.1 and had several user created
> functions fail.

> Recreating the failure with "SELECT xmlelement(name foo,
> 'infinity'::timestamp)
> ERROR: timestamp out of range
> DETAIL: XML does not support infinite timestamp values.

> I don't find anything in the documentation that explains this.  I
> consider this a regression.

So far as I can tell, Postgres has rejected converting infinite timestamps
to XML since 8.3 (cf commit 7b76bfbe1).  Certainly the above example fails
exactly like that in 9.2.  If you think there's a regression here, you
need to show us a case that actually behaves differently in 9.2 and 9.6.

(Speculating wildly, I imagine that your problem has something to do with
9.6 trying to fold a subexpression to a constant in a case where 9.2
didn't, and in fact didn't evaluate the subexpression at all.  But you'd
need a much larger example to demonstrate such a behavior.)

            regards, tom lane


Re: [GENERAL] xmlelement AND timestamps.

From
"David G. Johnston"
Date:
On Mon, Feb 13, 2017 at 7:10 PM, David G. Johnston <david.g.johnston@gmail.com> wrote:
XML itself is textual and we don't have any internal support for DTD or Schema as it is so I'm not sure what material benefit we gain by restraining ourselves here.

​This apparently isn't true - the XML output representations include schema-verifiable namespaces and ​thus have a well-defined allowable set of output values and formats.  While not every use case may have or need these at present their presence is embedded into the implementation - making any desired change non-trivial to evaluate.

David J.

Re: [GENERAL] xmlelement AND timestamps.

From
Lynn Dobbs
Date:

Well, I couldn't reproduce allowing infinite timestamps in 9.2.4 either.

While fixing some other minor issues that came up in the migration to 9.6.1, I copied a replaced good functions with bad ones.

The good functions called another function when putting my starting,ending columns in xml.  That function dates the timestamp or date and formats it and converts to text.

The documentation does say, "The particular behavior for individual data types is expected to evolve in order to align the SQL and PostgreSQL data types with the XML Schema specification, ...."  I didn't go chasing that down.  My bad.

My bad functions were written using the xml2 extension that treated the xml as text rather than "real" xml. 

Lynn Dobbs
Chief Technical Office
CreditLink Corporation
858-496-1000 x 103
On 02/13/2017 06:10 PM, David G. Johnston wrote:
On Mon, Feb 13, 2017 at 6:36 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 02/13/2017 02:56 PM, Lynn Dobbs wrote:
I just migrated from 9.2.4 to 9.6.1 and had several user created
functions fail.

Recreating the failure with "SELECT xmlelement(name foo,
'infinity'::timestamp)
ERROR: timestamp out of range
DETAIL: XML does not support infinite timestamp values.

I don't find anything in the documentation that explains this.  I
consider this a regression.

All I could find was this thread from 2009:

https://www.postgresql.org/message-id/41F26B729B014C3E8F20F5B7%40teje

which indicated it was fixed at that time.

​Actually, the cause of said commit (circa 2009) is that xmlelements were failing but xmlattributes were not​...which makes me wonder how a 9.2 era release (circa 2012) supposedly worked with the submitted expression.

The basic answer is that the XML data type is defined by standard and we attempt to conform to the standard.  In order to do so we must disallow infinite timestamps even though we accept them in SQL.

I just tested the OP query on 9.0.x and 9.4.x and get the same error on both.

There'd be a bit more sympathy if the OP were complaining about a patch release changing behavior - bug fix or not - but since the complaint involves going from 9.2 to 9.6 on its face this is an allowed behavior change regardless of the history.

However, feel free to make a straight argument for accepting infinite timestamps and thus go above-and-beyond the relevant standards.  Personally this seems like a not-so-useful restriction on our implementation.  Let the user decide whether they want to deviate from the standard and risk cross-system incompatibilities.  XML itself is textual and we don't have any internal support for DTD or Schema as it is so I'm not sure what material benefit we gain by restraining ourselves here.

David J.