Re: [PATCHES] to_date() validation - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: [PATCHES] to_date() validation
Date
Msg-id 37ed240d0809090546v3024a465j33216e8157bc54ca@mail.gmail.com
Whole thread Raw
In response to Re: [PATCHES] to_date() validation  ("Brendan Jurd" <direvus@gmail.com>)
Responses Re: [PATCHES] to_date() validation  ("Alex Hunsaker" <badalex@gmail.com>)
Re: [PATCHES] to_date() validation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Sep 9, 2008 at 9:04 PM, Brendan Jurd <direvus@gmail.com> wrote:
> On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
> <kleptog@svana.org> wrote:
>> The use of palloc/pfree in this routine seems excessive. Does len have
>> upper bound? If so a simple array will do it.
>>
>
> I suppose I could define a constant FORMATNODE_MAX_LEN, make it
> something like 10 and just use that for copying the string, rather
> than palloc().  I'll give it a try.
>

Turns out there was already a relevant constant defined in
formatting.c: DCH_MAX_ITEM_SIZ, set to 9.  So I just used that, +1 for
the trailing null.

>>
>> Here you do not note if we didn't convert the entire string. So it
>> seems you are allowed to provide too few characters, as long as it's
>> not the last field?
>
> That's true.  The only way to hit that condition would be to provide a
> semi-bogus value in a string with no separators between the numbers.

I've now plugged this hole.  I added the following error for
fixed-width inputs that are too short:

postgres=# SELECT to_date('200%1010', 'YYYYMMDD');
ERROR:  invalid value for "YYYY" in source string
DETAIL:  Field requires 4 characters, but only 3 could be parsed.
HINT:  If your source string is not fixed-width, try using the "FM" modifier.

I've attached a new version of the patch (version 3), as well as an
incremental patch to show the differences between versions 2 and 3.

Cheers,
BJ

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Synchronous Log Shipping Replication
Next
From: Tom Lane
Date:
Subject: Re: Synchronous Log Shipping Replication