approve cyD83L unsubscribe pgsql-patches [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
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_
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
Hello everyone,
This is my first post to this list.
Sorry if my english it's not so good. It's not my native language.
I'm interested if someone think that having a feature like 'thousands
comma delimited numbers' in psql is a good thing.
I have made a patch for psql that adds this functionality
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,
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
Hello,
This is my first post to this list.
Sorry if my english it's not so good. It's not my native language.
I'm interrested to now if someone think that having a feature like
'thousands comma delimited numeric formatting' in psql it's a
usefull thing.
I've made a patch for psql that adds this
