Mark Dilger wrote:
> I've been going through a copy of the code and replacing int32 and uint32
> with the appropriate type such as Oid, TransactionId, and such, and have
> created my own typedef for TypeModType, in order to help chase through
> the code and figure out what functions handle what kind of data. By
> defining TypeModType to int64, for example, I get lots of compiler errors
> when passing a TypeModType * into a function that takes int32 *, and that
> lets me know that the callers of that function think of it as a typemod
> argument,
> even if it does not have any clear documentation to that effect.
>
> The exercise is a bit tedious, as I have to change lots of strings like
> "the value %d is out of bounds" to something like
> "the value " TYPEMODTYPE_FORMAT " is out of bounds", but the clarity
> I get from it helps enough that it is useful to me.
If it weren't for the format string issue, which makes translations
impossible, I'd say let's go ahead with these ideas. For all the
drawbacks that a 64-bit TransactionId has, I'm sure there's people who
would prefer that to the constant vacuuming the 32-bit system causes.
But the int32/TypModType thing looks like we could carry without causing
any trouble at all. Not the format string part of it, though. How
large is a patch that changes typmod from int32 to TypModType?
I can see value in having 64-bit OIDs, for databases with large number
of toasted items. Not in the default build, mind you.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services