Re: OIDs, CTIDs, updateable cursors and friends

> > Ok, it seems to me there are several options here.
> > 1. Find out which is the primary key for the
> table. What
> > happens if the primary key is a multi-row thing?
> What happens
> > if there is no primary key?
>
> I guess you mean multicolumn? No different, you just
> need all columns in
> your WHERE clause. If there is no pkey (and I would
> be inclined to say
> if there is none in the user's query and not try to
> add it yourself)
> then you fail with an error.
>
> > 2. If I'm in a transaction, use OID for the insert
> after
> > checking with a select that I'm only affecting one
> row. If
> > I'm not in a transaction - perform the update in a
> generated
> > transaction, and roll it back if there is more
> than one row affected.
> >
> > I like 1 better, frankly. Dillemas dillemas
> dillemas.
>
> 1 is definitely better and is the only way that is
> guaranteed to be
> safe. Thinking about it more, that is almost
> certainly the position a
> driver should take. In pgAdmin we can afford a
> little artistic licence
> (no pun intended) because no one will be using
> pgAdmin as a driver to
> connect another program to a database, plus we can
> ask the user what
> action to take if we don't know if the result will
> be exactly what was
> intended. You do not have that luxury in a driver of
> course.

Just as another datapoint, pgaccess does the same
thing (finding the pkey(s), and using those to
uniquely identify the row). It is kind of a PITA, but
as Dave says, it's the best way to do this.

HTH,

--brett

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools