Hello,

this patch ensures independency datetime fields on current datestyle
setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust same to
USE_ISO_DATESTYLE. Differences are for timestamp:

ISO: yyyy-mm-dd hh24:mi:ss
XSD: yyyy-mm-ddThh24:mi:ss

I found one link about this topic:
http://forums.oracle.com/forums/thre...67278&tstart=0

Regards
Pavel Stehule

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


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
> this patch ensures independency datetime fields on current datestyle
> setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust same to
> USE_ISO_DATESTYLE. Differences are for timestamp:

> ISO: yyyy-mm-dd hh24:mi:ss
> XSD: yyyy-mm-ddThh24:mi:ss

Why is that a good idea? Even if some standard out there mandates the
'T', I'd bet lunch that the other format is a whole lot more portable.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

>"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
> > this patch ensures independency datetime fields on current datestyle
> > setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust same
>to
> > USE_ISO_DATESTYLE. Differences are for timestamp:
>
> > ISO: yyyy-mm-dd hh24:mi:ss
> > XSD: yyyy-mm-ddThh24:mi:ss
>
>Why is that a good idea? Even if some standard out there mandates the
>'T', I'd bet lunch that the other format is a whole lot more portable.
>

if you use xsd schema then situation is clear. I have to respect it, because
xsd:datetime is well defined and SQL/XML expect respecting xsd. If I don't
use xsd schema, then I teoreticly can put date in any format. Sample: we use
german format, but everybody with good mind doesn't use it for xml, because
then he cannot use xml validation based on xsd schema.

xsd format use Oracle 10g:
http://forums.oracle.com/forums/thre...67278&tstart=0
9x used ISO format, which is (however) invalid.

http://books.xmlschemata.org/relaxng/ch19-77049.html

Currently without this patch PostgreSQL generate invalalid xml documents.
That is all.

My patch doesn't protect any output. Simply use cast to text, or to_char
fce.

nice a day
Pavel Stehule

__________________________________________________ _______________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/


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

Pavel Stehule wrote:
> Hello,
>
> this patch ensures independency datetime fields on current datestyle
> setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust
> same to USE_ISO_DATESTYLE. Differences are for timestamp:
>
> ISO: yyyy-mm-dd hh24:mi:ss
> XSD: yyyy-mm-ddThh24:mi:ss
>
>


Pavel,

I agree that we should have some support for XSD date style so that we
can produce validatable XML documents. In fact I had to make just such a
transformation on data pulled from Postgres recently in application code
to get a document to validate.

However, I have not seen this topic discussed on -hackers. The way we
work is that ideas about features should be discussed there before you
submit a patch. For one thing, -hackers has a somewhat wider set of
readers than -patches. Also, you might well get good ideas about any
likely difficulties. Just lobbing a patch for an undiscussed feature
over the wall like this is not good practice. You should get signoff on
the idea before you start coding, even for fairly small changes.

cheers

andrew

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

>Pavel Stehule wrote:
>>Hello,
>>
>>this patch ensures independency datetime fields on current datestyle
>>setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust same
>>to USE_ISO_DATESTYLE. Differences are for timestamp:
>>
>>ISO: yyyy-mm-dd hh24:mi:ss
>>XSD: yyyy-mm-ddThh24:mi:ss
>>
>>
>
>
>Pavel,
>
>I agree that we should have some support for XSD date style so that we can
>produce validatable XML documents. In fact I had to make just such a
>transformation on data pulled from Postgres recently in application code to
>get a document to validate.
>
>However, I have not seen this topic discussed on -hackers. The way we work
>is that ideas about features should be discussed there before you submit a
>patch. For one thing, -hackers has a somewhat wider set of readers than
>-patches. Also, you might well get good ideas about any likely
>difficulties. Just lobbing a patch for an undiscussed feature over the wall
>like this is not good practice. You should get signoff on the idea before
>you start coding, even for fairly small changes.
>

I am sorry. I reported this two times before. This patch is related only for
xml functionality. XSD datestyle is only one internal constant. There are no
new datestyle (I hope so can be usefull). My patch is small bug fix like
Peter's patch for boolean datatype. Generating invalid xml is bug not
feature, no?

Primary I had to send this patch to Peter.

nice a day
Pavel Stehule

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


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Pavel Stehule wrote:
>
>> Pavel Stehule wrote:
>>> Hello,
>>>
>>> this patch ensures independency datetime fields on current datestyle
>>> setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust
>>> same to USE_ISO_DATESTYLE. Differences are for timestamp:
>>>
>>> ISO: yyyy-mm-dd hh24:mi:ss
>>> XSD: yyyy-mm-ddThh24:mi:ss
>>>
>>>
>>
>>
>> Pavel,
>>
>> I agree that we should have some support for XSD date style so that
>> we can produce validatable XML documents. In fact I had to make just
>> such a transformation on data pulled from Postgres recently in
>> application code to get a document to validate.
>>
>> However, I have not seen this topic discussed on -hackers. The way we
>> work is that ideas about features should be discussed there before
>> you submit a patch. For one thing, -hackers has a somewhat wider set
>> of readers than -patches. Also, you might well get good ideas about
>> any likely difficulties. Just lobbing a patch for an undiscussed
>> feature over the wall like this is not good practice. You should get
>> signoff on the idea before you start coding, even for fairly small
>> changes.
>>
>
> I am sorry. I reported this two times before. This patch is related
> only for xml functionality. XSD datestyle is only one internal
> constant. There are no new datestyle (I hope so can be usefull). My
> patch is small bug fix like Peter's patch for boolean datatype.
> Generating invalid xml is bug not feature, no?
>
> Primary I had to send this patch to Peter.
>
>

I'm not sure that we are actually guaranteeing anything about XML
validity against any schema or DTD, are we?

If there was previous email I apologise, as I didn't find it when I
looked. Perhaps in such cases you could include a ref to the archive URL.

cheers

andrew


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

On Tue, Feb 20, 2007 at 04:32:28PM +0100, Pavel Stehule wrote:
>
> I am sorry. I reported this two times before. This patch is related only
> for xml functionality. XSD datestyle is only one internal constant. There
> are no new datestyle (I hope so can be usefull). My patch is small bug fix
> like Peter's patch for boolean datatype. Generating invalid xml is bug not
> feature, no?

If it's just for XSD, perhaps it should be a part of the XML output
functionality instead of being a "global" datestyle?

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

>I'm not sure that we are actually guaranteeing anything about XML validity
>against any schema or DTD, are we?

what?

ofcourse you cannot garant validity against any schema. But mapping
functions are standardised and expect xsd. And I what I can meet protocols
based on xml, they respect xsd everywhere.

I repeat. When XML functions don't produce XML schema, then all is possible.
But using xsd standard is safe way (like ISO format in SQL world). With
nested XML schema whitch is related to xsd there isn't any different way.

The best solution is validation XML before output to client. pg have to
produce everytime valid xml

>
>If there was previous email I apologise, as I didn't find it when I looked.
>Perhaps in such cases you could include a ref to the archive URL.
>
>cheers
>
>andrew
>

__________________________________________________ _______________
With tax season right around the corner, make sure to follow these few
simple tips.
http://articles.moneycentral.msn.com...d=HMFebtagline


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

>
>On Tue, Feb 20, 2007 at 04:32:28PM +0100, Pavel Stehule wrote:
> >
> > I am sorry. I reported this two times before. This patch is related only
> > for xml functionality. XSD datestyle is only one internal constant.
>There
> > are no new datestyle (I hope so can be usefull). My patch is small bug
>fix
> > like Peter's patch for boolean datatype. Generating invalid xml is bug
>not
> > feature, no?
>
>If it's just for XSD, perhaps it should be a part of the XML output
>functionality instead of being a "global" datestyle?
>

I share code and I needed one safe enum value. That's all. There isn't new
global datestyle. I didn't want to duplicate code from timestamp.c and
date.c.

Pavel

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


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Am Dienstag, 20. Februar 2007 16:54 schrieb Andrew Dunstan:
> I'm not sure that we are actually guaranteeing anything about XML
> validity against any schema or DTD, are we?

That is the "xmlschema" part of table_to_xmlschema() et al. recently
discussed. That entire functionality hinges on producing output that
validates against XML Schema schemas, and so we cannot pick the data type
formats outselves.

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match