> But if these types are to have parameterizable sizes, I think it's
> critical that oidNin() and int2Nin() be robust about the number of
> input values they see. I suggest that they ought to work like this:
>
> * if the number of supplied values is less than the currently configured
> value of N, silently fill in zeroes for the extra places.
>
> * if the number of supplied values is more than N, check the extra
> values to see if any are not 0. Complain if any are not 0, but
> if they are all 0 then silently accept it.
>
> This will allow interoperability of pg_dump files across different
> values of N, and raise an error only if there's really a problem.
OK, different solution. I decided there is no need to be dumping out
zeros to pad the type. New code does the following. This looks very
clean to me:
test=> create table x (y int28);CREATEtest=> insert into x values ('1 2 3');INSERT 18697 1test=> select * from x; y
-------1 2 3(1 row)test=> insert into x values ('1 2 3 4 5 6 7 8');INSERT 18699 1test=> select * from x; y
----------------- 1 2 3 1 2 3 4 5 6 7 8(3 rows)test=> insert into x values ('1 2 3 4 5 6 7 8 9');ERROR: int28 value
hastoo many valuestest=> insert into x values ('1 2 3 4 5 6 7 8 0');ERROR: int28 value has too many values
Notice the trailing zero is treated as an error. Because we trim
trailing zeros, we can affort do handle things this way.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026