Re: [v9.3] writable foreign tables
Thom Brown <thom@linux.com>
From: Thom Brown <thom@linux.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>, Daniel Farina <daniel@heroku.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2013-03-10T20:55:28Z
Lists: pgsql-hackers
On 10 March 2013 20:38, Thom Brown <thom@linux.com> wrote: > On 10 March 2013 18:32, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Kohei KaiGai <kaigai@kaigai.gr.jp> writes: >>> [ pgsql-v9.3-writable-fdw-poc.v12.part-1/2.patch ] >> >> Applied after rather extensive editorialization. DELETE RETURNING in >> particular was a mess, and I also tried to make SELECT FOR UPDATE behave >> in what seemed like a sane fashion. >> >> There's a lot left to do here of course. One thing I was wondering >> about was why we don't allow DEFAULTs to be attached to foreign-table >> columns. There was no use in it before, but it seems sensible enough >> now. > > Yes... > > postgres=# INSERT INTO animals (id, animal, age) VALUES (DEFAULT, > 'okapi', NULL); > ERROR: null value in column "id" violates not-null constraint > DETAIL: Failing row contains (null, okapi, null). > CONTEXT: Remote SQL command: INSERT INTO public.animals(id, animal, > age) VALUES ($1, $2, $3) > > Out of curiosity, is there any way to explicitly force a foreign > DEFAULT with column-omission? Looks like we'll also need tab-completion for UPDATE, INSERT and DELETE statements on foreign tables. -- Thom
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