Re: OIDs, CTIDs, updateable cursors and friends - Mailing list pgsql-hackers

From Dave Page
Subject Re: OIDs, CTIDs, updateable cursors and friends
Date
Msg-id 03AF4E498C591348A42FC93DEA9661B889F3CD@mail.vale-housing.co.uk
Whole thread Raw
In response to OIDs, CTIDs, updateable cursors and friends  (Shachar Shemesh <psql@shemesh.biz>)
Responses Re: OIDs, CTIDs, updateable cursors and friends  (Shachar Shemesh <psql@shemesh.biz>)
Re: OIDs, CTIDs, updateable cursors and friends  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> -----Original Message-----
> From: Shachar Shemesh [mailto:psql@shemesh.biz]
> Sent: 18 February 2004 13:18
> To: Hackers; PostgreSQL OLE DB development
> Subject: [HACKERS] OIDs, CTIDs, updateable cursors and friends
>
> Would adding "OID" to the rows returned by each "Select"
> call, and then doing "update blah where oid=xxx" when I'm
> requested to update the row sound like a reasonable stategy,
> in lieu of updateable cursors? Can anyone suggest a better way?
>

Ignoring potential OID wraparound problems (which we do in pgAdmin) this
should work, assuming there is an OID column. I would suggest trying the
following methods in sequence:

1) Use the tables primary key.
2) Use the OID (and check that only one record will be affected).
3) Build a where clause based on all known original values (and check
that only one record will be affected).
4) Fail with an appropriate error.

2 & 3 can potentially affect more than one record, but even Microsoft
code runs into that problem from time to time and fails with an
appropriate error message. In pgAdmin II we used to ask the user if they
wanted to update all matching rows, but of course that is not
appropriate in a driver.

Regards, Dave.


pgsql-hackers by date:

Previous
From: Shachar Shemesh
Date:
Subject: OIDs, CTIDs, updateable cursors and friends
Next
From: Shachar Shemesh
Date:
Subject: Re: OIDs, CTIDs, updateable cursors and friends