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:38:21Z
Lists: pgsql-hackers
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?

--
Thom


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix postgres_fdw's issues with inconsistent interpretation of data values.