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
table_with_text_and_numeric_fields;
>
> 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,
Eugen
---------------------------(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
