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);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