Re: [HACKERS] MIN not defined for OID types - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] MIN not defined for OID types
Date
Msg-id 35F14F7D.CB56CC31@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] MIN not defined for OID types  (Bruce Momjian <maillist@candle.pha.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] MIN not defined for OID types
Next
From: Bruce Momjian
Date:
Subject: new office webcam