Re: [HACKERS] Number of index fields configurable

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> Shouldn't the following catalog be changed ?
> >>
> >> CATALOG(pg_index)
> >> {
> >> ....
> >> int28 indkey;
> >> ^^^^^
> >> oid8 indclass;
> >> ^^^^^
>
> > The underlying definitions of the types are now based in the #define
> > parameter. Not sure if this is going to work so I have not change the
> > actual type names yet. I have a few more changes to commit now.
>
> If we think the parameter works, then we should test it by changing
> the value ;-)
>
> > Also, what should the new names be? Can't call it int16.
>
> I like oidN and int2N, or oidn and int2n if you object to uppercase
> names.

How about oidvector and int2vector. A vector is a 1-dimmensional array.
Calling it an array is too confusing.

>
> > Does anyone outside the source tree rely on those type names?
>
> I was worried about that at first --- we couldn't change the names
> if it would break pg_dump files. But the system catalogs themselves
> don't get dumped as such, so it shouldn't be a problem. There might
> be a few folks out there who are using oid8 or int28 as column types
> in user tables, but surely not many. What it comes down to is that
> a few people might have to tweak their code or dump files, but not
> very many compared to the number of people who will be glad of the
> improvement.

>
> 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.

I will tweek the code to properly check for trailing numbers. Right now
multiple spaces cause problems, and trailing numbers are ignored. With
oidn, we can get away with trailing zeros because an oid of 0 is
invalid, but with int2n, a zero is valid, so I think we can't just ignore
extra trailing zeros. We can pad with zeros, however. Comments?

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