I didn't believe it at first:
create table test ( x double precision);
insert into test values (0.3);
test=# select * from test;
x
-
0.3
--
-- Data for TOC entry 3 (OID 53248)
-- Name: test; Type: TABLE DATA; Schema: public; Owner: christof
--
COPY test (x) FROM stdin;
0.2
Christof Petig <[EMAIL PROTECTED]> writes:
> COPY test (x) FROM stdin;
> 0.2
> \.
This is not a bug; it's pg_dump trying to recreate the actual floating
point value as accurately as it can. See the discussion of
extra_float_digits from six months or a year back.
Tom Lane schrieb:
Christof Petig <[EMAIL PROTECTED]> writes:
COPY test (x) FROM stdin;
0.2
\.
This is not a bug; it's pg_dump trying to recreate the actual floating
point value as accurately as it can. See the discussion of
extra_float_digits from six months or a year back.
Oh,
Christof Petig <[EMAIL PROTECTED]> writes:
> Commenting out "set extra_float_digits=2" in pg_dump.c gives me the old
> behaviour. Is it only me wishing for a command line parameter for
> pg_dump to set desired precision?
It seems to me that you should be using type NUMERIC if you think there
is
Tom Lane schrieb:
Christof Petig <[EMAIL PROTECTED]> writes:
Commenting out "set extra_float_digits=2" in pg_dump.c gives me the old
behaviour. Is it only me wishing for a command line parameter for
pg_dump to set desired precision?
It seems to me that you should be using type NUMERIC if you t
This is the initdb.log for my OS X 10.3.1 system.
the install was made with.
./configure
make
make check.
Ted
Running in noclean mode. Mistakes will not be cleaned
up.
The files belonging to this database system will be
owned by user "postgres".
This user must also own the server process.
Th
Theodore Petrosky <[EMAIL PROTECTED]> writes:
> FATAL: could not create shared memory segment: Cannot
> allocate memory
> DETAIL: Failed system call was shmget(key=1,
> size=1081344, 03600).
You need to increase SHMMAX.
regards, tom lane
---(end
