The attached patch is just a refreshed version for clean applying to
the latest tree.
As previous version doing, it makes pseudo enhancement on file_fdw
to print something about the supplied tuple on INSERT, UPDATE and
DELETE statement.
Here is one other idea. My GPU acceleration module (PG-Strom)
implements column-oriented data store underlying foreign table.
It might make sense to cut out this portion for proof-of-concept of
writable foreign tables.
Any ideas?
2012/11/8 Atri Sharma <atri.jiit@gmail.com>:
>
>
> On 08-Nov-2012, at 13:35, "Albe Laurenz" <laurenz.albe@wien.gv.at> wrote:
>
>> Alexander Korotkov wrote:
>>> 2) You wrote that FDW can support or don't support write depending on
>> having corresponding functions.
>>> However it's likely some tables of same FDW could be writable while
>> another are not. I think we should
>>> have some mechanism for FDW telling whether particular table is
>> writable.
>>
>> I think that this would best be handled by a table option,
>> if necessary.
>> That allows maximum flexibility for the design of the FDW.
>> In many cases it might be enough if the foreign data source
>> raises an error on a write request.
>>
>> Yours,
>> Laurenz Albe
>>
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>
> +1
>
> I agree, we should have a system where if the foreign data source raises an error on write, FDW can raise
correspondingerror on PostgreSQL side.exposing this as a table option is IMHO a bit risky, and the user may not know
whetherthe foreign data source will accept writes or not.
>
> Atri
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
