From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | "Andreas 'ads' Scherbaum" <adsmail(at)wars-nicht(dot)de> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: to_date_valid() |
Date: | 2016-07-04 14:33:38 |
Message-ID: | CAA4eK1LbSxyo8kW_+bwomsgQ3pAOh_BwCopOkYzBACwAB==KOg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jul 3, 2016 at 6:34 AM, Andreas 'ads' Scherbaum
<adsmail(at)wars-nicht(dot)de> wrote:
>
> Hello,
>
> we have customers complaining that to_date() accepts invalid dates, and
> returns a different date instead. This is a known issue:
>
> http://sql-info.de/postgresql/notes/to_date-to_timestamp-gotchas.html
>
> On the other hand this leads to wrong dates when loading dates into the
> database, because the database happily accepts invalid dates and ends up
> writing something completely different into the table.
>
> The attached patch adds a new function "to_date_valid()" which will validate
> the date and return an error if the input and output date do not match.
> Tests included, documentation update as well.
>
It seems that you are calling many additional function calls
(date_out, timestamp_in, etc.) to validate the date. Won't the
additional function calls make to_date much costlier than its current
implementation? I don't know if there is a better way, but I think it
is worth to consider, if we can find a cheaper way to detect validity
of date.
Note - Your patch is small (~13KB) enough that it doesn't need to zipped.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-07-04 14:34:27 | Re: Cluster on NAS and data center. |
Previous Message | Amit Kapila | 2016-07-04 13:58:51 | Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC] |