On Wed, Mar 13, 2013 at 9:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Merlin Moncure <mmonc...@gmail.com> writes: >> On Wed, Mar 6, 2013 at 11:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Yeah, I considered that. I thought seriously about proposing that we >>> forget magic row identifiers altogether, and instead make postgres_fdw >>> require a remote primary key for a foreign table to be updatable. > >> IMO, Utilizing anything but this for remote record identification is >> an implementation specific optimization. Aren't the semantics >> different though? If you go: > >> update foo set id = 1 where id = 1; > >> the primary key would not change, but the ctid would. or is that >> already a handled? > > In postgres_fdw as it currently stands, the remote ctid would change. > I'm not sure we should posit that as a universal property of FDWs > though. It's not even a meaningful question for FDWs with no underlying > rowid concept.
I just find it odd that rowid concept is used at all without strong guarantee that the record you are referencing is the one you are supposed to be referencing. Basically I'm saying PKEY semantics are the correct ones and that ctid is ok to use iff they match the pkey ones. I don't think this is possible unless you maintain a remote lock on the ctid between when you fetch it and do some other operation. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
