Re: WIP: to_char, support for EEEE format
От | Brendan Jurd |
---|---|
Тема | Re: WIP: to_char, support for EEEE format |
Дата | |
Msg-id | 37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: to_char, support for EEEE format (Euler Taveira de Oliveira <euler@timbira.com>) |
Ответы |
Re: WIP: to_char, support for EEEE format
(Pavel Stehule <pavel.stehule@gmail.com>)
Re: WIP: to_char, support for EEEE format (Euler Taveira de Oliveira <euler@timbira.com>) |
Список | pgsql-hackers |
2009/7/29 Euler Taveira de Oliveira <euler@timbira.com>: > This is not a problem with your patch but something that needs to be fixed in > PostgreSQL to match Oracle behavior. The following example should emit an > error. IMHO, filling the string with # is very strange. TODO? > > euler=# SELECT to_char(1234.56789, '9.080'); > to_char > --------- > #.#8# > (1 row) The formatting functions have a lot of weird corner cases. I've been trying to clean up some of the more bizarre behaviours in the date/time formatting functions, but haven't touched the numeric formatting because I haven't ever needed to use it. Filling unused characters in the string with "#" may be strange, but changing it would require a much broader patch that covers all of the numeric formatting styles, not just EEEE. A TODO is probably the way to go. > > Couldn't the following code be put inside switch clause? If not, you should > add a comment why the validation is outside switch. > > + if (IS_EEEE(num) && n->key->id != NUM_E) > + { > + NUM_cache_remove(last_NUMCacheEntry); > + ereport(ERROR, > + (errcode(ERRCODE_SYNTAX_ERROR), > + errmsg("\"EEEE\" must be the last pattern used"))); > + } > + > switch (n->key->id) > { > case NUM_9: The switch is on (n->key->id), but the test you mentioned above is looking for any keywords *other than* the EEEE keyword, where EEEE has previously been parsed. So if you put the test inside the switch, it would need to appear in every single branch of the switch except for the NUM_E one. I'm confused about why you think this needs a comment. Perhaps I misunderstood you? > > Oracle has a diferent overflow limit [1] but I think we could stay with the > PostgreSQL one. But the #.#### is not the intended behavior. IIRC you're > limited to 99 exponent. > > SQL> SELECT to_char(1.234567E+308, '9.999EEEE'); > SELECT to_char(1.234567E+308, '9.999EEEE') > > ERROR at line 1: > ORA-01426: numeric overflow > > euler=# SELECT to_char(1.234567E+308, '9.999EEEE'); > to_char > ----------- > #.####### > (1 row) I don't see any problem with extending this to allow up to 3 exponent digits ... Pavel, any comment? > > The problem is in numeric_to_char() and float8_to_char(). You could fix it > with the following code. Besides that I think you should comment why '5' or > '6' in the other *_to_char() functions. > > + /* 6 means '.' (decimal point), 'E', '+', and 3 exponent digits */ Agreed about the comment; I'll add it. Cheers, BJ
В списке pgsql-hackers по дате отправления: