Re: [v9.3] writable foreign tables
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Albe Laurenz" <laurenz.albe@wien.gv.at>
Cc: "Kohei KaiGai" <kaigai@kaigai.gr.jp>, "Robert Haas" <robertmhaas@gmail.com>, "PgHacker" <pgsql-hackers@postgresql.org>, "Shigeru Hanada" <shigeru.hanada@gmail.com>
Date: 2012-09-13T14:32:54Z
Lists: pgsql-hackers
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes: > Tom Lane wrote: >> Instead, the planner arranges for the TID to be carried up as an >> explicit resjunk column named ctid. (Currently this is done in >> rewriteTargetListUD(), but see also preptlist.c which does some >> related things for SELECT FOR UPDATE.) >> >> I'm inclined to think that what we need here is for FDWs to be able to >> modify the details of that behavior, at least to the extent of being >> able to specify a different data type than TID for the row >> identification column. > Would that imply inventing a new system attribute for > "foreign tid"? No, I think you missed the point of what I wrote completely. The target row ID is not treated as a system attribute during UPDATE/DELETE. It's an ordinary data column that's silently added to what the user wrote. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix postgres_fdw's issues with inconsistent interpretation of data values.
- cc3f281ffb0a 9.3.0 cited