pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Nissim <nissim@nksystems.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: [PATCH] Datatype of OID should be VARBINARY, not INT
Date: Fri, 16 Jun 2000 13:56:38 -0400
Message-ID: <394A6A56.ADFC63A2@nksystems.com> (raw)
References: <394A3D07.C1542D05@nksystems.com>
	<7249.961167897@sss.pgh.pa.us>

Tom Lane wrote:
> 
> Nissim <nissim@nksystems.com> writes:
> > The datatype returned by the ResultSetMetaData for OID should be
> > VARBINARY, not INT.
> 
> Uh, why?  There's nothing VAR about it that I can see, and it is
> the same size as INT ... at the moment anyway ...
> 
>                         regards, tom lane

If you're using it to identify rows then it is used like an int, but if
you're using it to point to a Large Object, the LO is variable size
binary data, right?

We're using it with village: http://www.working-dogs.com/village which
decides which set method of the PreparedStatement to use, based on the
type in the MetaData. If the type returned is INTEGER then it does
setInt, and if the type is BINARY or VARBINARY it does setBytes.  Do you
have a better solution than making the change I sent in the patch?

Will returning VARBINARY as the type of an OID column break anyone elses
apps?

	-Nissim



view thread (4+ messages)  latest in thread

Message-ID: <394A6A56.ADFC63A2@nksystems.com>
Permalink:  ../394A6A56.ADFC63A2@nksystems.com/
Also on:    postgresql.org/message-id/394A6A56.ADFC63A2@nksystems.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: nissim@nksystems.com, tgl@sss.pgh.pa.us
  Subject: Re: [PATCH] Datatype of OID should be VARBINARY, not INT
  In-Reply-To: <394A6A56.ADFC63A2@nksystems.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox