Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M243493=pgsql-hackers-arkari@postgresql.org>)
 id 1W8u6u-0001kf-5x
 for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Jan 2014 16:05:00 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M243493=pgsql-hackers-arkari@postgresql.org>)
 id 1W8u6t-0008Ug-Ln
 for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Jan 2014 16:04:59 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <tgl@sss.pgh.pa.us>) id 1W8u6r-0008Sb-9m
 for pgsql-hackers@postgresql.org; Thu, 30 Jan 2014 16:04:57 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
 by magus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <tgl@sss.pgh.pa.us>) id 1W8u6o-0000iB-S4
 for pgsql-hackers@postgresql.org; Thu, 30 Jan 2014 16:04:56 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
 by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s0UG4pNW032649;
 Thu, 30 Jan 2014 11:04:51 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Shigeru Hanada <shigeru.hanada@gmail.com>
cc: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: inherit support for foreign tables
In-reply-to: 
 <CAEZqfEfYauyxZQvsKODM5BQKt+KsnNakFQxrHHdnivq6mO83rg@mail.gmail.com>
References: 
 <CAEZqfEfVJNptoTSEY3QrQ90K9WD2nxfM+6fsk3YTc1ZXZ1Y5-g@mail.gmail.com>
 <12432.1384406906@sss.pgh.pa.us>
 <CA+Tgmob3ZNDi+P+v3ypHvFN1tD-Bpt8M+0dHFTnCqHxmcNw8aQ@mail.gmail.com>
 <10163.1384786524@sss.pgh.pa.us>
 <CAEZqfEc6MkEx+L=bQHVPEjr_+LgWSzy8uA11ci=X0A8VEPRmiw@mail.gmail.com>
 <52DDD071.9090405@ak.jp.nec.com>
 <CAEZqfEe_enXpSFpS8S_q6a8gNHK8AKtD5vy=fYxTddRtR8uOmw@mail.gmail.com>
 <CA+TgmoZiskpRfmSZuY01Uh3qBqPRb3-UgXnS-euUO5cw9Yst3Q@mail.gmail.com>
 <52E5F3FD.6050000@lab.ntt.co.jp> <52E6137B.1080704@lab.ntt.co.jp>
 <CAEZqfEdojfdzt9pHwsdYURNL5+JNrDUF-iMtmyh-LdDeAWcncA@mail.gmail.com>
 <CAEZqfEfYauyxZQvsKODM5BQKt+KsnNakFQxrHHdnivq6mO83rg@mail.gmail.com>
Comments: In-reply-to Shigeru Hanada <shigeru.hanada@gmail.com>
 message dated "Thu, 30 Jan 2014 14:01:10 +0900"
Date: Thu, 30 Jan 2014 11:04:51 -0500
Message-ID: <32648.1391097891@sss.pgh.pa.us>
X-Pg-Spam-Score: -2.3 (--)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Shigeru Hanada <shigeru.hanada@gmail.com> writes:
> At the moment we don't use attstorage for foreign tables, so allowing
> SET STORAGE against foreign tables never introduce visible change
> except \d+ output of foreign tables.  But IMO such operation should
> not allowed because users would be confused.  So I changed
> ATExecSetStorage() to skip on foreign tables.

I think this is totally misguided.  Who's to say that some weird FDW
might not pay attention to attstorage?  I could imagine a file-based
FDW using that to decide whether to compress columns, for instance.
Admittedly, the chances of that aren't large, but it's pretty hard
to argue that going out of our way to prevent it is a useful activity.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers