Re: Invalid to_date patterns (was: [PATCHES] [GENERAL] ISO week dates)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm picking this one up again, since my refactor of formatting.c has
been applied, and I seem to be done playing with psql for the time
being =)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: http://getfiregpg.org

iD8DBQFIFOAe5YBsbHkuyV0RAjHtAJ41opoNgu8M4jYTz9wsR2YGQNnDJQCgqNM0
RKNzCRnHUFwyNjSB3O3k0c8=
=andX
-----END PGP SIGNATURE-----

On Wed, Jul 18, 2007 at 10:00 AM, Brendan Jurd <direvus(at)gmail(dot)com> wrote:
> On 7/18/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > This is all good but I think that self-inconsistent format strings are
> > not really the main source of to_date problems. Most of the complaints
> > I've seen arise from to_date plowing ahead to deliver a ridiculous
> > answer when the input data string doesn't match the format. I'd like to
> > see the code try a little harder to validate the input data.
>
> Agreed, but so far it doesn't look like there's much overlap between
> the parsing and validating code and the stuff I'm playing with.
>
> I'll keep an eye out for any opportunities to improve on this, but it
> might end up being a separate TODO.
>

Actually, it turns out that there was an opportunity to improve on
validation. At the moment I'm experimenting with using strtol to
harvest integer values from the input string, instead of sscanf. So
far the results are promising. I've got the code throwing errors for
a few different kinds of bogus input:

* String is too short
* Value is out of range
* Value isn't an integer at all

I'm also getting rid of some more code duplication in do_to_timestamp.
I hope to have something worth posting to -patches in the near
future.

Cheers,
BJ