On 9/18/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Hmm ... I was thinking it didn't matter, but on closer look, the
int4->oid cast is implicit while the oid->int4 one is only assignment.
So you'd need to write a cast to pass an OID if we declare the functions
as taking int4.  But you'll need a cast anyway if you want to pass a
single OID to the int8-taking version (that's an assignment cast too).

The downside of declaring the functions to take OID is that people might
think they could *only* use OIDs, which isn't so, they can use any
int4-sized key they feel like.

hm. this is really a byproduct of oid being the catchall unsigned int4
type since it has the most built in casts.  i agree 100% though on the
oid perception however, i don't like userland oids at all, until such
time as an 8 bit one comes out.  i would say leave as int4 unless you
were willing to sql typedef the oid to some other name.


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to