(2014/01/28 0:55), Atri Sharma wrote:
>> On 27-Jan-2014, at 21:03, David Fetter <david@fetter.org> wrote:
>>> On Mon, Jan 27, 2014 at 05:06:19PM +0900, Etsuro Fujita wrote:
>>> Hi Hanada-san,
>>>
>>> While still reviwing this patch, I feel this patch has given enough
>>> consideration to interactions with other commands, but found the
>>> following incorrect? behabior:
>>>
>>> postgres=# CREATE TABLE product (id INTEGER, description TEXT);
>>> CREATE TABLE
>>> postgres=# CREATE FOREIGN TABLE product1 () INHERITS (product)
>>> SERVER fs OPTIONS (filename '/home/foo/product1.csv', format 'csv');
>>> CREATE FOREIGN TABLE
>>> postgres=# ALTER TABLE product ALTER COLUMN description SET STORAGE
>>> EXTERNAL;
>>> ERROR: "product1" is not a table or materialized view
>>>
>>> ISTN the ALTER TABLE simple recursion mechanism (ie
>>> ATSimpleRecursion()) should be modified for the ALTER COLUMN SET
>>> STORAGE case.
>>
>> This points to a larger discussion about what precisely foreign tables
>> can and cannot inherit from local ones. I don't think that a generic
>> solution will be satisfactory, as the PostgreSQL FDW could, at least
>> in principle, support many more than the CSV FDW, as shown above.
>>
>> In my estimation, the outcome of discussion above is not a blocker for
>> this
I just thought that among the structures that local tables can alter,
the ones that foreign tables also can by ALTER FOREIGN TABLE are
inherited, and the others are not inherited. So for the case as shown
above, I thought that we silently ignore executing the ALTER COLUMN SET
STORAGE command for the foreign table. I wonder that would be the first
step.
> I wonder what shall be the cases when foreign table is on a server which does not support *all* SQL features.
>
> Does a FDW need to have the possible inherit options mentioned in its documentation for this patch?
The answer is no, in my understanding. The altering operation simply
declares some chages for foreign tables in the inheritance tree and does
nothing to the underlying storages.
Thanks,
Best regards,
Etsuro Fujita
