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
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.
2012/11/8 Atri Sharma <atri(dot)jiit(at)gmail(dot)com>:
> On 08-Nov-2012, at 13:35, "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)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
>> 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.
>> Laurenz Albe
>> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>> To make changes to your subscription:
> I agree, we should have a system where if the foreign data source raises an error on write, FDW can raise corresponding error on PostgreSQL side.exposing this as a table option is IMHO a bit risky, and the user may not know whether the foreign data source will accept writes or not.
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
In response to
pgsql-hackers by date
|Next:||From: Cédric Villemain||Date: 2012-11-15 17:58:06|
|Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL|
|Previous:||From: Peter Eisentraut||Date: 2012-11-15 17:53:15|
|Subject: another idea for changing global configuration settings from SQL|