Re: [GENERAL] xmlelement AND timestamps.

2017-02-14 Thread Lynn Dobbs

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.kla...@aklaver.com <mailto:adrian.kla...@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
<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.




[GENERAL] xmlelement AND timestamps.

2017-02-13 Thread Lynn Dobbs
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



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] query_to_xml nulls set to false

2011-07-11 Thread Lynn Dobbs
I am using query_to_xml with nulls set to false in postgresql 9.0.4.  (I
believe the behavior was also present in 8.4.)

The documentation for query_to_xml says that if set to true, nulls with
be treated with xsi:nil=true and An appropriate namespace declaration
will be added to the result value. If false, columns containing null
values are simply omitted from the output.

This suggests to me that if set to false, there should be no added
namespace declaration, but, in practice, the xsi namespace is present.

Is this the designed, intentional behavior or accidental?

Lynn Dobbs

Chief Technical Officer
CreditLink Corporation
858 496 1010 x 103