Re: [HACKERS] MIN not defined for OID types
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] MIN not defined for OID types |
Дата | |
Msg-id | 35F14F7D.CB56CC31@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] MIN not defined for OID types (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
> Aren't oid's unsigned int, while int4 is signed. How > does binary compatable indexes handle this. Do oid's grater than 2gig > work with the int4 indexes? Do negative integers work with oid indexes? Good point. I have specified that OIDs are binary compatible with ints, and in cases where the types mix and there are not explicit operators/functions then the OIDs and ints are evaluated as signed quantities. At the moment, I don't see this as a _big_ problem, in that formerly the _only_ way of specifying OIDs above 2^^31 in size was to use the "stringified" syntax of OID '4000000000' or '4000000000'::OID and if one does that now one gets the right thing. All the platforms we run on use twos-complement integers, so signed and unsigned quantities below 2^^32-1 are binary equivalent. But at the least it is sloppy. So perhaps in the future we should have more explicit functions and operators on OIDs to avoid having to choose between signed and unsigned evaluation. At that point, we should probably no longer consider it equivalent to an integer, but rather have explicit conversion. When we have indices available for constant functions then the automatic conversion will work better; I'd made OIDs and int4s equivalent to solve the problem that SELECT * FROM foo WHERE oid = 100; did not use an index on oid even if it were available, but that SELECT * FROM foo WHERE oid = '100'::oid did. - Tom
В списке pgsql-hackers по дате отправления: