Sergio Lob wrote:
What should they return instead in this case?

-O

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Precision is the number of total digits in the number. Scale is the
number of fractional digits.
For instance, a column defined as NUMERIC(10,3) should return
precision=10, scale=3. The error only occurs for a column defined as
NUMERIC (without precision or scale specified). Presumably, there is a
default precision and scale assigned to the column by postgreSQL, which
is not -1.
Sergio

Oliver Jowett wrote:


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Wed, Mar 23, 2005 at 04:13:22PM -0500, Sergio Lob wrote:
That assumption is wrong. There is no default.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"La primera ley de las demostraciones en vivo es: no trate de usar el sistema.
Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Wed, 23 Mar 2005, Sergio Lob wrote:

IIRC, there is not a default precision and scale assigned to the column.
It's treated as having an unspecified precision and scale.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Sergio Lob wrote:
Yes, I understand that.

There appears to be no default, which is why we currently return -1.

Scale should default to 0 per the standard, but defaults to whatever the
precision is in PostgreSQL (see the docs for details).

The docs claim an implementation precision limit of 1000, but that
doesn't seem to correspond to the actual implementation -- I can insert
and retrieve 2000 digits NUMERICs (for example) just fine. I can't see
an obvious limit on precision in the backend code. There may be a
theoretical limit somewhere around 2^30 digits, I think (limited by the
backend's memory allocation sanity checks), but I have not tested that.

Given that there is effectively no default, do you have suggestions for
a better value to return?

-O

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Oliver Jowett <oliver (AT) opencloud (DOT) com> writes:
The spec's notion of a "default precision and scale" is that every
numeric column has a specific precision and scale --- ie, is physically
fixed-width --- and everything you store into it will be coerced to that
precision and scale. Postgres doesn't do it that way, which is why the
notion of a default is a bit meaningless.

If you specify a precision only, we do assume scale 0 to go with it.
It's only the case of an unconstrained numeric column that we depart
from the spec for.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org