Thanks, fix attached and applied
---
Eugen Nedelcu wrote:
> In function format_numericsep() you have:
>
> new_str = pg_local_malloc(len_numericseps(my_str) + 1),
>
> instead of:
>
> new_str = pg_local_malloc(len_with_nume
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > OK, I have applied the following patch to make numerisep a boolean,
> >
> > "numericsep" is no longer even remotely reasonable as a name for the
> > parameter. Something like "numeric_use_locale" would be appropriate
> > (but
In function format_numericsep() you have:
new_str = pg_local_malloc(len_numericseps(my_str) + 1),
instead of:
new_str = pg_local_malloc(len_with_numericsep(my_str) + 1)
Another bug is in function len_numericseps(). This apear for querys
like:
select NULL::numeric; or
select * from table_with_
Eugen Nedelcu wrote:
> The new code is broken. Please test it with resonably large tables.
> Do not test it with querys like: select -132323435.34343;
>
> If I use a query like:
>
> select * from my_table limit 100;
>
> I can't see anything on my screen until I hit CTRL^C
>
> If I use a pager (
The new code is broken. Please test it with resonably large tables.
Do not test it with querys like: select -132323435.34343;
If I use a query like:
select * from my_table limit 100;
I can't see anything on my screen until I hit CTRL^C
If I use a pager (\pset pager less) strange things happened
Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I have applied the following patch to make numerisep a boolean,
>
> "numericsep" is no longer even remotely reasonable as a name for the
> parameter. Something like "numeric_use_locale" would be appropriate
> (but probably too wordy).
Basically, w
Tom Lane wrote:
> > The only question I have is whether those locale values are single-byte
> > strings in all locals, or could they be multi-byte or multi-character,
> > in which case I have to treat them as strings.
>
> I think you have to assume they could be strings.
OK, the following applied
Bruce Momjian writes:
> OK, I have applied the following patch to make numerisep a boolean,
"numericsep" is no longer even remotely reasonable as a name for the
parameter. Something like "numeric_use_locale" would be appropriate
(but probably too wordy).
> The only question I have is whether th
Am Donnerstag, 14. Juli 2005 10:48 schrieb Bruce Momjian:
> OK, I have applied the following patch to make numerisep a boolean, made
> it locale-aware, set defaults if the locale doesn't return meaningful
> values, added code to handle locale-reported groupings, and updated the
> documentation.
Th
Eugen Nedelcu wrote:
> Regarding locale aproach, it is trivial to replace langinfo with
> localeconv:
>
> struct lconv *l = localeconv();
> char *dec_point = l->decimal_point;
>
> instead of:
>
> #include langinfo.h
> char *dec_point = nl_langinfo(__DECIMAL_POINT);
>
> I used langinfo because i
Thanks, fixed, and applied. I also centralized the malloc into a
function. We could use pg_malloc, but that doesn't export out to
/scripts, where this is shared. We will fix that some day, but not
right now.
---
Eugen Ned
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > I have heavily modified your patch and have applied it. Instead of
> > using langinfo, I used a \pset variable numericsep.
>
> Why?
Because I don't have langinfo on my system, so I can't test it, nor add
configure code for it. It also prevents
Bruce Momjian wrote:
> I have heavily modified your patch and have applied it. Instead of
> using langinfo, I used a \pset variable numericsep.
Why?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6: expl
Eugen Nedelcu wrote:
> Hello,
>
> I have included my patch attached to this mail.
>
> I have made the changes to deal with locale settings from client
> environment. So now you can start psql like this:
>
> (export LC_ALL=ro_RO; psql -U user db)
>
> and have numeric formatting with '.' as thous
Hello,
I have included my patch attached to this mail.
I have made the changes to deal with locale settings from client
environment. So now you can start psql like this:
(export LC_ALL=ro_RO; psql -U user db)
and have numeric formatting with '.' as thousands separator and
',' as decimal point,
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Tue, Jun 21, 2005 at 04:03:43PM +0300, Eugen Nedelcu wrote:
>> This is a patch for psql client and not for the backend.
> I think it would be much nicer if it was a backend setting.
Doing this as a backend setting has been proposed and rejected befo
On Tue, Jun 21, 2005 at 04:03:43PM +0300, Eugen Nedelcu wrote:
> This is a patch for psql client and not for the backend. It's role
> is to output numbers to screen in easy readable form (2,345,675,454,543
> is much easier to read then 2345675454543.456). I think graphical
> clients like pgAdmin
On Tue, Jun 21, 2005 at 16:03:43 +0300,
Eugen Nedelcu <[EMAIL PROTECTED]> wrote:
>
> This is a patch for psql client and not for the backend. It's role
> is to output numbers to screen in easy readable form (2,345,675,454,543
> is much easier to read then 2345675454543.456). I think graphical
>
On Tue, Jun 21, 2005 at 06:59:38AM -0500, Bruno Wolff III wrote:
> On Tue, Jun 21, 2005 at 08:42:16 +0300,
> Eugen Nedelcu <[EMAIL PROTECTED]> wrote:
> >
> > One solution to deal with this is to use to_char function, but for
> > complex selects against multiple tables it's not a good option.
>
On Tue, Jun 21, 2005 at 08:42:16 +0300,
Eugen Nedelcu <[EMAIL PROTECTED]> wrote:
>
> One solution to deal with this is to use to_char function, but for
> complex selects against multiple tables it's not a good option.
Why not? You only have to apply it to the output expressions that
need it.
N
20 matches
Mail list logo
