2009/8/11 Pavel Stehule pavel.steh...@gmail.com:
It's nice. I am playing with it, and now I found some potential issue.
The parser is maybe too tolerant:
postgres=# select to_char(3.14323,'9.9(a');
to_char
--
3.1e+00
(1 row)
I guess we *could* add code to throw an error
2009/8/11 Tom Lane t...@sss.pgh.pa.us:
Brendan Jurd dire...@gmail.com writes:
Here's version 7.
Applied with a couple of corrections: the numeric case wasn't dealing
with NaNs in the same way as the float cases,
Thanks for that.
I do think that the whole business of printing #.# is
Brendan Jurd wrote:
2009/8/11 Tom Lane t...@sss.pgh.pa.us:
Brendan Jurd dire...@gmail.com writes:
Here's version 7.
Applied with a couple of corrections: the numeric case wasn't dealing
with NaNs in the same way as the float cases,
Thanks for that.
I do think that the whole
Brendan Jurd escribió:
2009/8/9 Alvaro Herrera alvhe...@commandprompt.com:
I noticed an ugly pattern in NUMDesc_prepare calling a cleanup function
before every ereport(ERROR). I think it's cleaner to replace that with
a PG_TRY block; see attached.
Looks nice -- although doesn't have
Alvaro Herrera alvhe...@commandprompt.com writes:
Got you thinking about what? I'd welcome any comments you have.
I wondered if it should just return char *. If we want to have this
functionality as its own fmgr-blessed function, shouldn't it return
text instead of cstring?
If we expose it
2009/8/11 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com writes:
I wondered if it should just return char *. If we want to have this
functionality as its own fmgr-blessed function, shouldn't it return
text instead of cstring?
If we expose it at fmgr level it should
Brendan Jurd dire...@gmail.com writes:
2009/8/11 Tom Lane t...@sss.pgh.pa.us:
If we expose it at fmgr level it should definitely not return cstring.
However, I wasn't foreseeing doing that --- does the submitted patch
expose it?
Sorry, I'm a little hazy on the terminology here. If by expose
2009/8/11 Tom Lane t...@sss.pgh.pa.us:
If it's not meant to be in pg_proc, I wouldn't bother with using the V1
call protocol for it. extern char *numeric_out_sci(Numeric x) would
be sufficient, and less notation on both caller and callee sides.
Thanks Tom. I have removed the V1 stuff as you
Brendan Jurd dire...@gmail.com writes:
Thanks Tom. I have removed the V1 stuff as you suggest, and placed
the declaration in numeric.h.
Here's version 7.
Working through this now, and I noticed that the example added to the
manual seems to be wrong:
entryliteralto_char(0.000485,
Tom Lane escribió:
Also, I'm wondering what should happen with
regression=# select to_char(0.000485, '99.99');
to_char
---
4.85e-04
(1 row)
Doesn't seem quite right. Should we throw error if the number of 9's
before the decimal point isn't 1?
No, see
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Doesn't seem quite right. Should we throw error if the number of 9's
before the decimal point isn't 1?
No, see
http://archives.postgresql.org/message-id/4a68fae4.50...@timbira.com
Ah, nothing like being bug-compatible
Tom Lane escribió:
BTW, this patch adds more NUM_cache_remove() calls. I'm planning
to commit it that way, unless you're just about to commit your PG_TRY
change? I agree with doing that, but figured it should be a separate
commit.
No, go ahead, I will commit that separately.
--
Alvaro
2009/8/11 Tom Lane t...@sss.pgh.pa.us:
Working through this now, and I noticed that the example added to the
manual seems to be wrong:
entryliteralto_char(0.000485, '9.99')/literal/entry
entryliteral' 4.850e-04'/literal/entry
With 9.99 as the pattern, I'd expect (and
Brendan Jurd dire...@gmail.com writes:
Here's version 7.
Applied with a couple of corrections: the numeric case wasn't dealing
with NaNs in the same way as the float cases, and the int8 case was
converting to float8 which would lose precision. I made it go through
numeric instead, which is
2009/8/10 Tom Lane t...@sss.pgh.pa.us:
Brendan Jurd dire...@gmail.com writes:
Here's version 7.
Applied with a couple of corrections: the numeric case wasn't dealing
with NaNs in the same way as the float cases, and the int8 case was
converting to float8 which would lose precision. I made
2009/8/9 Tom Lane t...@sss.pgh.pa.us:
Brendan Jurd dire...@gmail.com writes:
That would allow for a maximum of 10 exponent digits. As an aside, I
note that int4out() hardcodes the maximum number of digits rather than
exposing a constant (c.f. MAXINT8LEN in int8.c). I'm considering
adding
Brendan Jurd escribió:
Here's version 6 of the patch, now with an all-new implementation
of (normalised) scientific notation in numeric.c, via the functions
numeric_out_sci() and get_str_from_var_sci(). So should now be
able to represent the full gamut of the numeric type.
I
2009/8/9 Alvaro Herrera alvhe...@commandprompt.com:
Brendan Jurd escribió:
Here's version 6 of the patch, now with an all-new implementation
of (normalised) scientific notation in numeric.c, via the functions
numeric_out_sci() and get_str_from_var_sci(). So should now be
able to
2009/8/3 Tom Lane t...@sss.pgh.pa.us:
Uh, no, we had better support more. The actual limit of the current
numeric format is 1e+131072.
Given your comment above I'm thinking it reasonable to use an int32 to
store the exponent -- will that be safe?
That would allow for a maximum of 10 exponent
Brendan Jurd dire...@gmail.com writes:
2009/8/3 Tom Lane t...@sss.pgh.pa.us:
Uh, no, we had better support more. The actual limit of the current
numeric format is 1e+131072.
Given your comment above I'm thinking it reasonable to use an int32 to
store the exponent -- will that be safe?
2009/8/3 Brendan Jurd dire...@gmail.com:
Okay, so Oracle just forces the output wider to accomodate the
exponent (i.e., you can't rely on it being fixed-width).
I can adjust the patch to imitate this behaviour; should be able to
post a new revision within 24 hours.
Please find attached
2009/8/3 Tom Lane t...@sss.pgh.pa.us:
Euler Taveira de Oliveira eu...@timbira.com writes:
As I said in a prior e-mail, Oracle has a diferent overflow limit (-84 to
127).
In PostgreSQL, the numeric datatype can have up to 1000 digits (ie 1e+999)
and
the double precision datatype can have up
Brendan Jurd dire...@gmail.com writes:
Well, I tried this and as it turns out the patch casts the value to a
float8 in order to pass it on to snprintf for sci-notation formatting.
Well, that's pretty dumb. Quite aside from the range problem, that
would mean that you lose everything past the
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
Brendan Jurd dire...@gmail.com writes:
Well, I tried this and as it turns out the patch casts the value to a
float8 in order to pass it on to snprintf for sci-notation formatting.
Well, that's pretty dumb. Quite aside from the range problem, that
would
Brendan Jurd dire...@gmail.com writes:
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
What I'd consider instead is calling numeric_out and then working
with the result of that. It would always be f-format, so you'd
have to do your own conversion to e-format, but you could do it
without any risk of
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
BTW, there's no rule saying you have to fix that strictly within
to_char(). It might make more sense to have numeric.c export a
function that is like numeric_out but produces e-style output.
Your choice as the patch writer, but keep it in mind ...
Ah,
On Thu, Jul 30, 2009 at 1:18 PM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/7/30 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote:
Hmm. For what
2009/8/2 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 1:18 PM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/7/30 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 10:35 AM, Brendan
Pavel Stehule pavel.steh...@gmail.com writes:
Tom, please, can you write your opinion on my last proposal - print
### with raise warning.
The idea of printing a warning seems completely horrid to me. From a
logical point of view, either we think it's an error or we don't. From
a practical
Tom Lane escreveu:
The real bottom line for to_char issues is almost always that we should
do what Oracle does. Has anyone checked this behavior on Oracle?
That was my point too. See [1].
[1] http://archives.postgresql.org/pgsql-hackers/2009-07/msg01870.php
--
Euler Taveira de Oliveira
2009/8/2 Euler Taveira de Oliveira eu...@timbira.com:
Tom Lane escreveu:
The real bottom line for to_char issues is almost always that we should
do what Oracle does. Has anyone checked this behavior on Oracle?
That was my point too. See [1].
[1]
2009/8/3 Pavel Stehule pavel.steh...@gmail.com:
2009/8/2 Euler Taveira de Oliveira eu...@timbira.com:
Tom Lane escreveu:
The real bottom line for to_char issues is almost always that we should
do what Oracle does. Has anyone checked this behavior on Oracle?
That was my point too. See [1].
Brendan Jurd escreveu:
Well, the examples Euler posted in the linked message above were using
E+308. If I'm reading the Oracle docs correctly, that would have
triggered Oracle's data type overflow error before even getting to
to_char(); Oracle's NUMBER type only supports up to E+126. So we
Euler Taveira de Oliveira eu...@timbira.com writes:
As I said in a prior e-mail, Oracle has a diferent overflow limit (-84 to
127).
In PostgreSQL, the numeric datatype can have up to 1000 digits (ie 1e+999) and
the double precision datatype can have up to 309 digits (ie 1e-307 or 1e+308).
We
2009/8/3 Euler Taveira de Oliveira eu...@timbira.com:
Brendan Jurd escreveu:
Euler, could you post results for a number which fits within Oracle's
data type but has three exponent digits (like 1E+100)?
I don't access to an Oracle Server now but it works fine up to the 127 limit.
And
2009/7/30 Pavel Stehule pavel.steh...@gmail.com:
2009/7/29 Brendan Jurd dire...@gmail.com:
I don't see any problem with extending this to allow up to 3 exponent
digits ... Pavel, any comment?
I am not sure - this function should be used in reports witl fixed
line's width. And I am thinking,
Brendan Jurd escreveu:
Hmm. For what it's worth, I think Pavel makes a good point about the
number of exponent digits -- a large chunk of the use case for numeric
formatting would be fixed-width reporting.
But it doesn't cover all numbers in the interval. And in this case, all
numbers can be
Brendan Jurd escreveu:
I can't imagine anyone reading the code getting confused about this,
and don't know how to go about writing a comment explaining something
that is intuitively obvious to me. I don't understand what aspect of
it requires explanation. The test is not in the switch
On Thu, Jul 30, 2009 at 12:17 PM, Euler Taveira de
Oliveiraeu...@timbira.com wrote:
Brendan Jurd escreveu:
I can't imagine anyone reading the code getting confused about this,
and don't know how to go about writing a comment explaining something
that is intuitively obvious to me. I don't
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote:
2009/7/30 Pavel Stehule pavel.steh...@gmail.com:
2009/7/29 Brendan Jurd dire...@gmail.com:
I don't see any problem with extending this to allow up to 3 exponent
digits ... Pavel, any comment?
I am not sure - this function
2009/7/30 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote:
2009/7/30 Pavel Stehule pavel.steh...@gmail.com:
2009/7/29 Brendan Jurd dire...@gmail.com:
I don't see any problem with extending this to allow up to 3 exponent
digits ...
2009/7/31 Euler Taveira de Oliveira eu...@timbira.com:
Brendan Jurd escreveu:
Limiting to two exponent digits also has the nice property that the
output always matches the length of the format pattern:
9.99
1.23E+02
I don't think neglecting to represent a valid number is a nice
Pavel Stehule pavel.steh...@gmail.com writes:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote:
Hmm. For what it's worth, I think Pavel makes a good point about the
number of exponent digits -- a large chunk of the use case for
On Thu, Jul 30, 2009 at 12:46 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote:
Hmm. For what it's worth, I think Pavel makes a good point about
Brendan Jurd escreveu:
2009/7/31 Euler Taveira de Oliveira eu...@timbira.com:
Brendan Jurd escreveu:
Limiting to two exponent digits also has the nice property that the
output always matches the length of the format pattern:
9.99
1.23E+02
I don't think neglecting to represent a valid
2009/7/30 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote:
Hmm. For what it's worth, I think Pavel makes a good point about the
number of exponent
2009/7/29 Euler Taveira de Oliveira eu...@timbira.com:
Looks better but I did some tests and caught some strange behaviors.
Pavel,
Any comment on these cases? When I looked at the patch I wasn't
really sure why it filled the string with '#' either, but I didn't
question it.
Cheers,
BJ
--
2009/7/29 Brendan Jurd dire...@gmail.com:
2009/7/29 Euler Taveira de Oliveira eu...@timbira.com:
Looks better but I did some tests and caught some strange behaviors.
Pavel,
Any comment on these cases? When I looked at the patch I wasn't
really sure why it filled the string with '#'
2009/7/29 Euler Taveira de Oliveira eu...@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
2009/7/29 Brendan Jurd dire...@gmail.com:
2009/7/29 Euler Taveira de Oliveira eu...@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
Brendan Jurd escreveu:
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 . A TODO is probably the way
to go.
That was my suggestion: a TODO.
So if you put the
On Sat, Jul 25, 2009 at 2:08 AM, Brendan Jurddire...@gmail.com wrote:
2009/7/24 Euler Taveira de Oliveira eu...@timbira.com:
Here is my review. The patch applied without problems. The docs and
regression
tests are included. Both of them worked as expected. Also, you included a fix
in RN
Brendan Jurd escreveu:
Please find attached version 4 of the patch, and incremental diff from
version 3. It fixes the bug ( is now accepted as a valid
form of ), and lifts the restriction on only having one digit
before the decimal point.
Looks better but I did some tests and
2009/7/24 Euler Taveira de Oliveira eu...@timbira.com:
Here is my review. The patch applied without problems. The docs and regression
tests are included. Both of them worked as expected. Also, you included a fix
in RN format, do it in another patch.
Well, I updated an error message for RN to
Brendan Jurd escreveu:
2009/4/26 Brendan Jurd dire...@gmail.com:
I've done some work updating Pavel's sci notation patch for to_char().
That patch again, now with a couple of minor tweaks to make it apply
cleanly against the current HEAD.
Here is my review. The patch applied without
2009/4/26 Brendan Jurd dire...@gmail.com:
I've done some work updating Pavel's sci notation patch for to_char().
That patch again, now with a couple of minor tweaks to make it apply
cleanly against the current HEAD.
Cheers,
BJ
_3.diff.bz2
Description: BZip2 compressed data
--
Sent via
On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
So, please, if you can, propose these error messages (with hints)-
result will be much better.
Hi Pavel, hackers.
I've done some work updating Pavel's sci notation patch for to_char().
I've attached a patch against
Hi Brendan
this looks well, so please, add it to commitfest page
regards
Pavel Stehule
2009/4/26 Brendan Jurd dire...@gmail.com:
On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
So, please, if you can, propose these error messages (with hints)-
result will be
On Wed, Apr 22, 2009 at 10:13 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/4/21 Brendan Jurd dire...@gmail.com:
numstr = orgnum = (char *) palloc(MAXDOUBLEWIDTH + 1);
if (Num.pre != 1)
ereport(ERROR,
On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
So, please, if you can, propose these error messages (with hints)-
result will be much better.
Hi Pavel,
I was doing some work on rewording these error messages, and I noticed
that the following code segment occurs
2009/4/21 Brendan Jurd dire...@gmail.com:
On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
So, please, if you can, propose these error messages (with hints)-
result will be much better.
Hi Pavel,
I was doing some work on rewording these error messages, and I
Hello
I was surprised so PostgreSQL doesn't support this basic output format.
Regards
Pavel Stehule
*** ./src/backend/utils/adt/formatting.c.orig 2009-04-10 11:31:17.0 +0200
--- ./src/backend/utils/adt/formatting.c 2009-04-10 18:05:14.0 +0200
***
*** 335,340
---
On Sat, Apr 11, 2009 at 2:16 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
I was surprised so PostgreSQL doesn't support this basic output format.
Hi Pavel,
I had a look through your patch and would like to suggest improvements
to the new error messages you've introduced.
1. invalid using
Hi,
I know very well, so all texts in my patches should be translated to
English. My language skills are really minimal.
So, please, if you can, propose these error messages (with hints)-
result will be much better.
Thank you
Pavel
2009/4/10 Brendan Jurd dire...@gmail.com:
On Sat, Apr 11,
64 matches
Mail list logo
