> -----Original Message-----
> From: Shachar Shemesh [mailto:psql@shemesh.biz]
> Sent: 18 February 2004 14:10
> To: Dave Page
> Cc: Hackers; PostgreSQL OLE DB development
> Subject: Re: [HACKERS] OIDs, CTIDs, updateable cursors and friends
>
>
> I would, except I'm not sure how many queries I would need in
> order to find what the primary key is.
Well this is the only safe way to update a specific record. To find the
pkey, look for an index on the table in pg_index with indisprimary =
true. The indkey column holds an array of pg_attribute.attnum's that are
in the index iirc.
> Also, what happens if
> the primary key is not a part of the fields returned by the query?
Add them as you proprosed to do with the OID, or fall back to the next
method. ADO etc. normally fail to update rows if the programmer hasn't
included a suitable key in the recordset.
> >2) Use the OID (and check that only one record will be affected).
> >
> >
> That may work. Do a query for "how many would be affected".
> Then again, I'm currently not inside a transaction. The plan
> was not to be inside a transaction unless I needed to. I'm
> not sure how safe this is to perform many queries.
Should be perfectly safe.
> >3) Build a where clause based on all known original values
> (and check
> >that only one record will be affected).
> >
> >
> Again - what happens when I'm not inside a transaction?
You might find a new row that wasn;t there before but is now, or vice
versa.
> The doc mentions something about making the OID column
> unique. Would that not cause other problems? What happens if
> I define the OID field as unique, and I get a wraparound and
> an attempt to put a new field in with existing value? Would
> the OID skip to the next unique per table, or would the insert fail?
It is not the drivers place to mess with peoples schemas, but yes, it
could cause an insert to fail following wraparound.
Regards, Dave.
