Re: [PATCHES] to_date() validation
От | Brendan Jurd |
---|---|
Тема | Re: [PATCHES] to_date() validation |
Дата | |
Msg-id | 37ed240d0809090546v3024a465j33216e8157bc54ca@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCHES] to_date() validation ("Brendan Jurd" <direvus@gmail.com>) |
Ответы |
Re: [PATCHES] to_date() validation
Re: [PATCHES] to_date() validation |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: