Philip Warner writes:
> At 22:29 20/02/01 +0100, Peter Eisentraut wrote:
> >Tom Lane writes:
> >> And we frequently see questions from users about how they can display
> >> fewer digits than the system wants to give them --- or, more
> >> generally, format the output in some special form.
> >
> >
At 22:29 20/02/01 +0100, Peter Eisentraut wrote:
>Tom Lane writes:
>> And we frequently see questions from users about how they can display
>> fewer digits than the system wants to give them --- or, more
>> generally, format the output in some special form.
>
>to_char() should serve those people.
At 15:48 20/02/01 -0500, Tom Lane wrote:
>
>The existing default of FLT_DIG or DBL_DIG digits seems like a good
>general-purpose policy, but it doesn't meet all needs. For pg_dump,
>we clearly would like to promise exact dump and restore. On the
>other side, the geometry regress tests would like
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> And we frequently see questions from users about how they can display
>> fewer digits than the system wants to give them --- or, more
>> generally, format the output in some special form.
> to_char() should serve those people.
On
Tom Lane writes:
> And we frequently see questions from users about how they can display
> fewer digits than the system wants to give them --- or, more
> generally, format the output in some special form.
to_char() should serve those people.
--
Peter Eisentraut [EMAIL PROTECTED] htt
> I think the idea of making a user-settable format string is a good one.
> I'm just afraid of the idea of trying to shoehorn in a solution at the
> last minute; if we do, we may find it's not quite right and then have
> a backwards-compatibility problem with fixing it. Besides, we are in
> "no n
Pete Forman <[EMAIL PROTECTED]> writes:
> Please remind me what we are trying to do.
The real point is that we need to serve several different purposes
that aren't necessarily fully compatible.
The existing default of FLT_DIG or DBL_DIG digits seems like a good
general-purpose policy, but it doe
Tom Lane writes:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The defaults
> >> would be "%.7g" and "%.17g" (or thereabouts, not sure what number of
> >> digits we are currently using).
>
> > Wouldn't changing current '%.6g','%.15g'(on many platforms)
> > cause the
Tom Lane wrote:
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Actually, you're going to have to recode the float*in() functions, using
> > scanf, and scanf's formats are not always equivalent to printf's.
>
> Further thought: one answer to this is to institute four SET variables,
> two for
> Hiroshi Inoue writes:
>
> > The 7.1-release seems near.
> > May I provide the followings ?
> > SET FLOAT4_PRECISION TO ..
> > SET FLOAT8_PRECISION TO ..
>
> I'd prefer names that go with the SQL type names:
>
> REAL_FORMAT
> DOUBLE_PRECISION_FORMAT
>
> Seems a bit tacky, but a lot of
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Actually, you're going to have to recode the float*in() functions, using
> scanf, and scanf's formats are not always equivalent to printf's.
Further thought: one answer to this is to institute four SET variables,
two for output and two for input; per
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Or must we postpone to fix it ?
> Actually, you're going to have to recode the float*in() functions, using
> scanf, and scanf's formats are not always equivalent to printf's.
Hmm... that wouldn't matter, except for this %a format. Maybe we'd
bette
Hiroshi Inoue writes:
> The 7.1-release seems near.
> May I provide the followings ?
> SET FLOAT4_PRECISION TO ..
> SET FLOAT8_PRECISION TO ..
>
> Or must we postpone to fix it ?
Actually, you're going to have to recode the float*in() functions, using
scanf, and scanf's formats are n
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
> * Add SET FLOAT4_PRECISION and SET FLOAT8_PRECISION using printf args
foo_PRECISION is not the right name if these variables will contain
printf format strings. Perhaps foo_FORMAT? Anyone have a better idea?
After further thoug
Hiroshi Inoue writes:
> The 7.1-release seems near.
> May I provide the followings ?
> SET FLOAT4_PRECISION TO ..
> SET FLOAT8_PRECISION TO ..
I'd prefer names that go with the SQL type names:
REAL_FORMAT
DOUBLE_PRECISION_FORMAT
Seems a bit tacky, but a lot of work has been put in
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > The 7.1-release seems near.
> > May I provide the followings ?
> > SET FLOAT4_PRECISION TO ..
> > SET FLOAT8_PRECISION TO ..
>
> > Or must we postpone to fix it ?
>
> This seems a small enough change that I do not fear fixing it at this
> l
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > The 7.1-release seems near.
> > May I provide the followings ?
> > SET FLOAT4_PRECISION TO ..
> > SET FLOAT8_PRECISION TO ..
>
> > Or must we postpone to fix it ?
>
> This seems a small enough change that I do not fear
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The defaults
>> would be "%.7g" and "%.17g" (or thereabouts, not sure what number of
>> digits we are currently using).
> Wouldn't changing current '%.6g','%.15g'(on many platforms)
> cause the regression test failure ?
I didn't che
I wrote:
>
> > -Original Message-
> > From: Tom Lane [mailto:[EMAIL PROTECTED]]
> >
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
[snip]
>
> > Peter's idea of a SET variable to control float display format might
> > not be a bad idea, but what if anything should pg_dump do with it?
>
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> The 7.1-release seems near.
> May I provide the followings ?
> SET FLOAT4_PRECISION TO ..
> SET FLOAT8_PRECISION TO ..
> Or must we postpone to fix it ?
This seems a small enough change that I do not fear fixing it at this
late date. Howev
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The GNU C library now offers a %a (and %A) format that prints floating
> > point numbers in a semi-internal form that is meant to be portable. (I
> > image this was done b
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The GNU C library now offers a %a (and %A) format that prints floating
> point numbers in a semi-internal form that is meant to be portable. (I
> image this was done because of C99, but I'm speculating.) It might be
> useful to offer this to preserv
Hiroshi Inoue writes:
> Is there a way to change the precision of floating
> point representation from clients ?
Not currently, but I image it couldn't be too hard to introduce a
parameter that changes the format string used by float*out to something
else.
The GNU C library now offers a %a (and
Hi all,
I have a question of PostgreSQL's floating point
representation.
create table t (fl1 float4, fl2 float4, fl3 float4);
insert into t values (1.234567, 1.23457, 1.23457);
select * from t;
fl1 | fl2 | fl3
-+-+-
1.23457 | 1.23457 | 1.23457
(1 row)
select *
24 matches
Mail list logo
