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.
> Why not? You only have to apply it to the output expressions that
> need it.

I think this:

select * from table_with_text_and_numeric_fields;

is much,much easier than:

select text_field1,text_field2,to_char(numeric_field1, '99G999G999'),
       to_char(numeric_field2, '9G999G999G999'), text_field3, 
       text_field4, to_char(numeric_field3, 'MI90G999D99') from

> Note that if you output numbers like this, you also need to be able to
> read them back in. I don't think adding complexity for doing that is
> worth not having to add a few to_char calls in your select queries.

I don't know what 'read them back in' means to you. 
This formatting is only done when the number is output to the screen.

Something like: 
    fputs(thousands_comma_number, fout)
instead of:
    fputs(original_number, fout)

If you want to output to some file for reading back later, you could
turn the feature off with the backslash switch '\n'.

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 or phppgadmin have a way to do this. I don't know 
this for sure but I will investigate it.

Best Regards,

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to