Philip Warner <[EMAIL PROTECTED]> writes:
> The other issues, like what is sent to psql & via interfaces like odbc
> (currently text) should be application/DBA based and setable on a
> per-attribute basis. eg. some applications want 1. because the data
> came from a piece of hardware with a kn
On Wed, 21 Feb 2001, you wrote:
> At 10:19 21/02/01 +0100, Robert Schrem wrote:
> >The advantage would be, that we only generate as much ASCII data
> >as absolutly neccessary to rebuild the original data exactly.
> >At least this is what I would expect from pg_dump.
>
> pg_dump is only one side o
At 10:19 21/02/01 +0100, Robert Schrem wrote:
>The advantage would be, that we only generate as much ASCII data
>as absolutly neccessary to rebuild the original data exactly.
>At least this is what I would expect from pg_dump.
pg_dump is only one side of thre problem, but the simplest solution mi
I think a formating mode where only the relevant digits are written
to the output would be great as an alternative to the discussed
fixed formatting strings. In this context i think of 'relevant'
as in the following:
'Output as few characters as possible but ensure that scanf is
still able to
> > ...right now I am worried about whether we'd be able to reconfirm regress
> > results on all the currently-supported platforms before release.
>
> This would be an excellent topic for a full development cycle ;)
Oh, I see. Never mind. I was lost.
--
Bruce Momjian
> ...right now I am worried about whether we'd be able to reconfirm regress
> results on all the currently-supported platforms before release.
This would be an excellent topic for a full development cycle ;)
- Thomas
> Hmm, on looking at the code, this might mean we need some configure
> pushups to extract FLT_DIG and DBL_DIG and put those into the default
> strings. Do we support any platforms where these are not 6 & 15?
In principle, yes. VAX does not use IEEE math (by default anyway) and
has less range an
