From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Noah Misch <noah@leadboat.com>
To: shigeru.hanada@gmail.com, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: pgsql-hackers@postgresql.org
Subject: Re: inherit support for foreign tables
Date: Thu, 21 Aug 2014 18:30:47 +0900
Message-ID: <53F5BC47.3080000@lab.ntt.co.jp> (raw)
In-Reply-To: <20140702022327.GC1586927@tornado.leadboat.com>
References: <53393E18.3080901@lab.ntt.co.jp>
<533C01C7.6030809@lab.ntt.co.jp>
<53706FB6.6000403@lab.ntt.co.jp>
<20140620.170406.123403564.horiguchi.kyotaro@lab.ntt.co.jp>
<20140702022327.GC1586927@tornado.leadboat.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
(2014/07/02 11:23), Noah Misch wrote:
> On Fri, Jun 20, 2014 at 05:04:06PM +0900, Kyotaro HORIGUCHI wrote:
>> Attached is the rebased patch of v11 up to the current master.
> The rest of these review comments are strictly observations; they're not
> requests for you to change the patch, but they may deserve more discussion.
>
> We use the term "child table" in many messages. Should that change to
> something more inclusive, now that the child may be a foreign table? Perhaps
> one of "child relation", plain "child", or "child foreign table"/"child table"
> depending on the actual object? "child relation" is robust technically, but
> it might add more confusion than it removes. Varying the message depending on
> the actual object feels like a waste. Opinions?
IMHO, I think that "child table" would not confusing users terribly.
> LOCK TABLE on the inheritance parent locks child foreign tables, but LOCK
> TABLE fails when given a foreign table directly. That's odd, but I see no
> cause to change it.
I agree wth that.
> The longstanding behavior of CREATE TABLE INHERITS is to reorder local columns
> to match the order found in parents. That is, both of these tables actually
> have columns in the order (a,b):
>
> create table parent (a int, b int);
> create table child (b int, a int) inherits (parent);
>
> Ordinary dump/reload always uses CREATE TABLE INHERITS, thereby changing
> column order in this way. (pg_dump --binary-upgrade uses ALTER TABLE INHERIT
> and some catalog hacks to avoid doing so.) I've never liked that dump/reload
> can change column order, but it's tolerable if you follow the best practice of
> always writing out column lists. The stakes rise for foreign tables, because
> column order is inherently significant to file_fdw and probably to certain
> other non-RDBMS FDWs. If pg_dump changes column order in your file_fdw
> foreign table, the table breaks. I would heartily support making pg_dump
> preserve column order for all inheritance children. That doesn't rise to the
> level of being a blocker for this patch, though.
I agree with that, too. I think it would be better to add docs for now.
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
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, noah@leadboat.com, horiguchi.kyotaro@lab.ntt.co.jp
Subject: Re: inherit support for foreign tables
In-Reply-To: <53F5BC47.3080000@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