Re: [v9.3] writable foreign tables - Mailing list pgsql-hackers

From Thom Brown
Subject Re: [v9.3] writable foreign tables
Date
Msg-id CAA-aLv71QL3YZ=mbhJsM1SzOzkNR7eOkJ6tMiq+=oHimf9TMBQ@mail.gmail.com
Whole thread Raw
In response to Re: [v9.3] writable foreign tables  (Thom Brown <thom@linux.com>)
List 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



pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: [v9.3] writable foreign tables
Next
From: Tom Lane
Date:
Subject: Re: [v9.3] writable foreign tables