Brendan Jurd wrote:
> 2009/8/11 Tom Lane :
> > Brendan Jurd 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 "#.##
2009/8/11 Tom Lane :
> Brendan Jurd 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 highly
bogus, and I might look a
2009/8/11 Pavel Stehule :
> 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 where the 9's
2009/8/10 Tom Lane :
> Brendan Jurd 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 instea
Brendan Jurd 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 pretty expensive but
2009/8/11 Tom Lane :
> Working through this now, and I noticed that the example added to the
> manual seems to be wrong:
>
> to_char(0.000485, '9.99')
> ' 4.850e-04'
>
> With 9.99 as the pattern, I'd expect (and indeed I get) 4.85e-04
> not 4.850e-04. This is correct behavior, no
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
Alvaro Herrera 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 with a bad implementati
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
http:
Brendan Jurd 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:
to_char(0.000485, '9.99')
' 4.850e-0
2009/8/11 Tom Lane :
> 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 suggest, and
Brendan Jurd writes:
> 2009/8/11 Tom Lane :
>> 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 it at
> fmgr level" you me
2009/8/11 Tom Lane :
> Alvaro Herrera 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 definitely not return cstring.
> Howe
Alvaro Herrera 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 at fmgr level it shou
Brendan Jurd escribió:
> 2009/8/9 Alvaro Herrera :
> > 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 anything to do with
2009/8/9 Alvaro Herrera :
> 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
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 no
2009/8/9 Tom Lane :
> Brendan Jurd 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 MAXINT2LEN and MAXINT4LEN to
Brendan Jurd writes:
> 2009/8/3 Tom Lane :
>> 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?
Seems reasonable to me.
> That w
2009/8/3 Tom Lane :
> 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 digits. As an
2009/8/4 Tom Lane :
> 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, thanks for the
Brendan Jurd writes:
> 2009/8/4 Tom Lane :
>> 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 precision or range loss.
> Y
2009/8/4 Tom Lane :
> Brendan Jurd 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 everythin
Brendan Jurd 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 sixteenth or so di
2009/8/3 Tom Lane :
> Euler Taveira de Oliveira 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
2009/8/3 Brendan Jurd :
> 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 version 5 of the
2009/8/3 Euler Taveira de Oliveira :
> 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 differently to wh
Euler Taveira de Oliveira 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 should suppo
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 w
2009/8/3 Pavel Stehule :
> 2009/8/2 Euler Taveira de Oliveira :
>> 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.po
2009/8/2 Euler Taveira de Oliveira :
> 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
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 Oliveir
Pavel Stehule 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 point of view, warnings u
2009/8/2 Robert Haas :
> On Thu, Jul 30, 2009 at 1:18 PM, Pavel Stehule wrote:
>> 2009/7/30 Tom Lane :
>>> Pavel Stehule writes:
2009/7/30 Robert Haas :
> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
>> Hmm. For what it's worth, I think Pavel makes a good point about the
On Thu, Jul 30, 2009 at 1:18 PM, Pavel Stehule wrote:
> 2009/7/30 Tom Lane :
>> Pavel Stehule writes:
>>> 2009/7/30 Robert Haas :
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
> Hmm. For what it's worth, I think Pavel makes a good point about the
> number of exponent digits --
2009/7/30 Tom Lane :
> Pavel Stehule writes:
>> 2009/7/30 Robert Haas :
>>> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd 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 numeric
formatting wo
Brendan Jurd escreveu:
> 2009/7/31 Euler Taveira de Oliveira :
>> 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 v
On Thu, Jul 30, 2009 at 12:46 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> 2009/7/30 Robert Haas :
>>> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd 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 f
Pavel Stehule writes:
> 2009/7/30 Robert Haas :
>> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd 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 numeric
>>> formatting would be fixed-width reporting
2009/7/31 Euler Taveira de Oliveira :
> 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 property".
2009/7/30 Robert Haas :
> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
>> 2009/7/30 Pavel Stehule :
>>> 2009/7/29 Brendan Jurd :
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 us
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
> 2009/7/30 Pavel Stehule :
>> 2009/7/29 Brendan Jurd :
>>> 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
On Thu, Jul 30, 2009 at 12:17 PM, Euler Taveira de
Oliveira 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 understand what
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 bec
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
2009/7/30 Euler Taveira de Oliveira :
>> 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?
>>
> Yes, I know you need to modif
2009/7/30 Pavel Stehule :
> 2009/7/29 Brendan Jurd :
>> 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, so it's should be problem - I pre
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
2009/7/29 Brendan Jurd :
> 2009/7/29 Euler Taveira de Oliveira :
>> 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
2009/7/29 Euler Taveira de Oliveira :
> 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
2009/7/29 Brendan Jurd :
> 2009/7/29 Euler Taveira de Oliveira :
>> 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
2009/7/29 Euler Taveira de Oliveira :
> 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
--
Sent via pgsql-ha
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 t
On Sat, Jul 25, 2009 at 2:08 AM, Brendan Jurd wrote:
> 2009/7/24 Euler Taveira de Oliveira :
>> 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
2009/7/24 Euler Taveira de Oliveira :
> 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 keep it consis
Brendan Jurd escreveu:
> 2009/4/26 Brendan Jurd :
>> 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 problems. The doc
2009/4/26 Brendan Jurd :
> 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 pgsql-hackers mail
Hi Brendan
this looks well, so please, add it to commitfest page
regards
Pavel Stehule
2009/4/26 Brendan Jurd :
> On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule
> wrote:
>> So, please, if you can, propose these error messages (with hints)-
>> result will be much better.
>>
>
> Hi Pavel, hacker
On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule 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 HEAD (_2.diff.bz
On Wed, Apr 22, 2009 at 10:13 AM, Pavel Stehule wrote:
> 2009/4/21 Brendan Jurd :
>> numstr = orgnum = (char *) palloc(MAXDOUBLEWIDTH + 1);
>> if (Num.pre != 1)
>> ereport(ERROR,
>> (errcode(ERRCODE_SYNTAX_
2009/4/21 Brendan Jurd :
> On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule
> 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
On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule 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 identically in four d
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 :
> On Sat, Apr 11, 2009 at 2:16 AM, Pa
On Sat, Apr 11, 2009 at 2:16 AM, Pavel Stehule 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 of format "
Th
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
--- 3
65 matches
Mail list logo
