From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Shigeru Hanada <shigeru.hanada@gmail.com>
Cc: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: inherit support for foreign tables
Date: Fri, 31 Jan 2014 10:21:36 -0500
Message-ID: <20140131152136.GJ2921@tamriel.snowman.net> (raw)
In-Reply-To: <CA+Tgmoa9yGWfq7Yybf6KYjXRJFarUh7pxCq6K_k86d-Xmf3QtA@mail.gmail.com>
References: <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>
* Robert Haas (robertmhaas@gmail.com) 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?
I agree that using the FDW-specific options is the right approach and
disallowing those to be set on foreign tables makes sense. I don't
particularly like the idea of applying changes during inheiritance
which we wouldn't allow the user to do directly. While it might be a
no-op and no FDW might use it, it'd still be confusing.
Thanks,
Stephen
Attachments:
[application/pgp-signature] signature.asc (835B, ../20140131152136.GJ2921@tamriel.snowman.net/2-signature.asc)
download
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: sfrost@snowman.net, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, shigeru.hanada@gmail.com, fujita.etsuro@lab.ntt.co.jp
Subject: Re: inherit support for foreign tables
In-Reply-To: <20140131152136.GJ2921@tamriel.snowman.net>
* 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