database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Tighten up to_date/to_timestamp so that they are more likely to reject

Browse Source 
erroneous input, rather than silently producing bizarre results as formerly
happened.

Brendan Jurd
This commit is contained in:
Tom Lane
2008-09-11 17:32:34 +00:00
parent 70530c808b
commit 06edce4c3f
8 changed files with 764 additions and 838 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
doc/src/sgml/func.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.446 2008/09/08 00:47:40 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.447 2008/09/11 17:32:33 tgl Exp $ -->
<chapter id="functions">
<title>Functions and Operators</title>
@ -5187,7 +5187,12 @@ SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1,3})');
</itemizedlist>
</para>
<para>
Attempting to construct a date using a mixture of ISO week and Gregorian date fields is nonsensical, and could yield unexpected results. In the context of an ISO year, the concept of a 'month' or 'day of month' has no meaning. In the context of a Gregorian year, the ISO week has no meaning. Users should take care to keep Gregorian and ISO date specifications separate.
Attempting to construct a date using a mixture of ISO week and
Gregorian date fields is nonsensical, and will cause an error. In the
context of an ISO year, the concept of a <quote>month</> or <quote>day
of month</> has no meaning. In the context of a Gregorian year, the
ISO week has no meaning. Users should take care to keep Gregorian and
ISO date specifications separate.
</para>
</listitem>