Bruce Momjian <pgman@candle.pha.pa.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.
> 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.
You have the first behavior but not the second...
regards, tom lane