pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Shigeru Hanada <shigeru.hanada@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: inherit support for foreign tables
Date: Mon, 03 Feb 2014 12:15:31 +0900
Message-ID: <52EF09D3.8060302@lab.ntt.co.jp> (raw)
In-Reply-To: <CA+Tgmoa9yGWfq7Yybf6KYjXRJFarUh7pxCq6K_k86d-Xmf3QtA@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>
	<32648.1391097891@sss.pgh.pa.us>
	<CA+TgmoZwhrVF5t6d6anyd1UOh=B6MuPB+uruuXtVo0gHH9txPg@mail.gmail.com>
	<20275.1391119500@sss.pgh.pa.us>
	<CA+Tgmoa9yGWfq7Yybf6KYjXRJFarUh7pxCq6K_k86d-Xmf3QtA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

(2014/01/31 9:56), Robert Haas wrote:
> On Thu, Jan 30, 2014 at 5:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> 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.
>>
>>> I think that's a pretty tenuous position.  There are already
>>> FDW-specific options sufficient to let a particular FDW store whatever
>>> kinds of options it likes; letting the user set options that were only
>>> ever intended to be applied to tables just because we can seems sort
>>> of dubious.  I'm tempted by the idea of continuing to disallow SET
>>> STORAGE on an unvarnished foreign table, but allowing it on an
>>> inheritance hierarchy that contains at least one real table, with the
>>> semantics that we quietly ignore the foreign tables and apply the
>>> operation to the plain tables.
>>
>> [ shrug... ] By far the easiest implementation of that is just to apply
>> the catalog change to all of them.  According to your assumptions, it'll
>> be a no-op on the foreign tables anyway.
>
> Well, there's some point to that, too, I suppose.  What do others think?

Allowing ALTER COLUMN SET STORAGE on foreign tables would make sense if 
for example, "SELECT * INTO local_table FROM foreign_table" did create a 
new local table of columns having the storage types associated with 
those of a foreign table?

Thanks,

Best regards,
Etsuro Fujita


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



view thread (179+ messages)  latest in thread

Message-ID: <52EF09D3.8060302@lab.ntt.co.jp>
Permalink:  ../52EF09D3.8060302@lab.ntt.co.jp/
Also on:    postgresql.org/message-id/52EF09D3.8060302@lab.ntt.co.jp

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: fujita.etsuro@lab.ntt.co.jp, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, shigeru.hanada@gmail.com
  Subject: Re: inherit support for foreign tables
  In-Reply-To: <52EF09D3.8060302@lab.ntt.co.jp>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox