Re: [PATCHES] [GENERAL] Different exponent in error messages
Tom Lane wrote: Michael Fuhr [EMAIL PROTECTED] writes: I think this is what Andrus is seeing: test= CREATE TABLE foo (n numeric(9,3)); CREATE TABLE test= INSERT INTO foo VALUES (100); ERROR: numeric field overflow DETAIL: The absolute value is greater than or equal to 10^6 for field with precision 9, scale 3. test= INSERT INTO foo VALUES (10); ERROR: numeric field overflow DETAIL: The absolute value is greater than or equal to 10^9 for field with precision 9, scale 3. Hm, I thought I tested that same case, but I must've messed up somehow. Anyway, the code seems to be intentionally reporting the log10 of the actual input value, not the limiting log10 for the field size. This behavior goes at least as far back as PG 7.0, so I'm disinclined to change it. We could talk about altering the message wording though, if you have a suggestion for something you'd find less confusing. Pre-7.4 versions say ERROR: overflow on numeric ABS(value) = 10^9 for field with precision 9 scale 3 so it looks like we just fixed the grammar during the 7.4 message wording cleanup, without reflecting about whether the meaning was clear. Yes, this message clearly needs help. Here is what I developed: test= CREATE TABLE foo (n numeric(9,3)); CREATE TABLE test= INSERT INTO foo VALUES (1000); ERROR: numeric field overflow DETAIL: A field with precision 9, scale 3 must have an absolute value less than 10^6. and the 10^6 is based on the max digits to the left of the decimal point, not the input value. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/backend/utils/adt/numeric.c === RCS file: /cvsroot/pgsql/src/backend/utils/adt/numeric.c,v retrieving revision 1.88 diff -c -c -r1.88 numeric.c *** src/backend/utils/adt/numeric.c 22 Nov 2005 18:17:23 - 1.88 --- src/backend/utils/adt/numeric.c 23 Jan 2006 20:00:54 - *** *** 3206,3213 ereport(ERROR, (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), errmsg(numeric field overflow), !errdetail(The absolute value is greater than or equal to 10^%d for field with precision %d, scale %d., ! ddigits - 1, precision, scale))); break; } ddigits -= DEC_DIGITS; --- 3206,3213 ereport(ERROR, (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), errmsg(numeric field overflow), !errdetail(A field with precision %d, scale %d must have an absolute value less than 10^%d., ! precision, scale, maxdigits))); break; } ddigits -= DEC_DIGITS; ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] CIDR/INET improvements
I looked into this, and it seems the easiest solution is to just call
network() if a cidr-cast value is output and the value is actually an
inet value internally.
Patch for testing attached. Passes regression tests. By affecting only
the output you can internally cast back and forth and only output is
affected. However, if you load in a dump that was interally inet but
was dumped out as cidr-cast, you lose the unmasked bits.
---
Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
Actually both types are not binary compatible, since they have a
type component that is either 0 or 1, depending on whether it is of type
INET or CIDR.
The whole question of the relationship of those types really needs to be
looked at more carefully. We've got this schizophrenic idea that they
sometimes are the same type and sometimes are not. ISTM that either
they are the same type (and having a bit within the data is reasonable)
or they are distinct types (in which case the bit within the data should
be redundant). I'm not sure which is better.
I think the reason why things are as they are right now is to avoid
needing a pile of redundant-seeming pg_proc entries, eg you'd need
both abbrev(inet) and abbrev(cidr) if you were taking a hard line
about them being different types.
You can *not* just throw in a cast that removes the bit without breaking
many of those functions for the CIDR case. For instance abbrev behaves
differently depending on the state of the bit:
regression=# select abbrev(cidr '10.1.0.0/16');
abbrev
-
10.1/16
(1 row)
regression=# select abbrev(inet '10.1.0.0/16');
abbrev
-
10.1.0.0/16
(1 row)
What about functions to get/set a specific byte, for example:
I would vote against adding any such thing in the absence of any strong
demand for it. I think functions that expose the underlying data just
encourage people to write IPv4-only code. If you can't define and use
the function in a way that handles both IPv4 and IPv6, you probably
shouldn't have it.
regards, tom lane
---(end of broadcast)---
TIP 1: 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
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/utils/adt/network.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/network.c,v
retrieving revision 1.60
diff -c -c -r1.60 network.c
*** src/backend/utils/adt/network.c 23 Jan 2006 21:49:39 - 1.60
--- src/backend/utils/adt/network.c 24 Jan 2006 04:05:52 -
***
*** 166,171
--- 166,181
Datum
cidr_out(PG_FUNCTION_ARGS)
{
+ inet *src = PG_GETARG_INET_P(0);
+
+ /* If this is an INET, zero any unmasked bits */
+ if (!ip_is_cidr(src))
+ {
+ Datum src2;
+
+ src2 = DirectFunctionCall1(network_network, PG_GETARG_DATUM(0));
+ fcinfo-arg[0] = src2;
+ }
return inet_out(fcinfo);
}
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] CIDR/INET improvements
Bruce Momjian pgman@candle.pha.pa.us writes: Patch for testing attached. This is an utterly bad idea, because it not only doesn't address the problem (ie, confusion about whether inet and cidr are distinct types or not), but it masks mistakes in that realm by hiding data on output. It'll be almost impossible to debug situations where x is different from y but they display the same. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
