On Tue, Sep 9, 2008 at 9:04 PM, Brendan Jurd <direvus(at)gmail(dot)com> wrote:
> On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
> <kleptog(at)svana(dot)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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2008-09-09 12:50:27|
|Subject: Re: Synchronous Log Shipping Replication |
|Previous:||From: Simon Riggs||Date: 2008-09-09 12:39:17|
|Subject: Re: Synchronous Log Shipping Replication|
pgsql-patches by date
|Next:||From: Kenneth Marshall||Date: 2008-09-09 13:48:39|
|Subject: Re: hash index improving v3|
|Previous:||From: Tom Lane||Date: 2008-09-09 12:11:45|
|Subject: Re: [PgFoundry] Unsigned Data Types [1 of 2] |