Nissim Karpenstein wrote:
>
> I'm replying to my own message because I found out the solution to the next
> (and final) postgres problem. The problem stems from the fact that the
> ResultSetMetaData (used by village) from pgsql identifies the OID field as
> an int (which it is in the table, but it really refers to VARBINARY data)
I was thinking about this and I am wondering if this is a safe way to
handle this problem. I found a definition of the OID type at:
http://www.postgresql.org/docs/faq-english.html#4.17
It says:
#################################
Oids are PostgreSQL's answer to unique row ids. Every row that is
created in PostgreSQL gets a unique oid. All oids generated during
initdb are less than 16384 (from backend/access/transam.h). All
user-created oids are equal or greater that this. By default, all these
oids are unique not only within a table, or database, but unique within
the entire PostgreSQL installation.
PostgreSQL uses oids in its internal system tables to link rows between
tables. These oids can be used to identify specific user rows and used
in joins. It is recommended you use column type oid to store oid values.
See the sql(l) manual page to see the other internal columns. You can
create an index on the oid field for faster access.
#################################
If OIDs are used by Postgres internally as integers, couldnt it possibly
cause unforseen problems if we change the type to VARBINARY?
John Thorhauer
--
********************************
** John Thorhauer
** Web Developer
** Phoenix Color Corp.
** [EMAIL PROTECTED]
********************************
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
