Re: [HACKERS] Number of index fields configurable

> 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);
CREATE
test=> insert into x values ('1 2 3');
INSERT 18697 1
test=> select * from x;
y
-------
1 2 3
(1 row)
test=> insert into x values ('1 2 3 4 5 6 7 8');
INSERT 18699 1
test=> 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 has too many values
test=> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026