From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Noah Misch <noah@leadboat.com>
Cc: Shigeru Hanada <shigeru.hanada@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: inherit support for foreign tables
Date: Mon, 20 Apr 2015 17:20:47 +0900
Message-ID: <5534B6DF.5060601@lab.ntt.co.jp> (raw)
In-Reply-To: <552F5F49.6000105@lab.ntt.co.jp>
References: <543D0261.6020803@lab.ntt.co.jp>
<54461BEB.9000707@lab.ntt.co.jp>
<5449EE98.1040704@lab.ntt.co.jp>
<20141107.145713.169337282.horiguchi.kyotaro@lab.ntt.co.jp>
<545CB4A2.1030303@lab.ntt.co.jp>
<CAFjFpRcVLtU6jE8h_N1Rc+Y-pDFbmR7YvBvxOXg6aTFrbZ1Z8Q@mail.gmail.com>
<54645499.7050709@lab.ntt.co.jp>
<CAFjFpRcBFVO0YP0nmfygpJOFfWKMkAN1Z8JmrkwyEWXDyMt5Hw@mail.gmail.com>
<CAFjFpRcd=F8Jqx+9yioHKVUA71LXBxO41ia61acjzyzQ4MZqVQ@mail.gmail.com>
<5476FB4B.9060705@lab.ntt.co.jp>
<CAFjFpRd6PR3Seg8D3t-XcXGxXyb+p2WDsk_wBGge7b=PyzP_Qw@mail.gmail.com>
<5487BB9D.7070605@lab.ntt.co.jp>
<30555.1418853840@sss.pgh.pa.us>
<5497FE79.7090804@lab.ntt.co.jp>
<19367.1419262577@sss.pgh.pa.us>
<54B76DD2.1040106@lab.ntt.co.jp>
<54E6DB4E.40801@lab.ntt.co.jp>
<21104.1427047056@sss.pgh.pa.us>
<552F5F49.6000105@lab.ntt.co.jp>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2015/04/16 16:05, Etsuro Fujita wrote:
> On 2015/03/23 2:57, Tom Lane wrote:
>> Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
>>> [ fdw-inh-8.patch ]
>>
>> I've committed this with some substantial rearrangements, notably:
>
>> * As I mentioned earlier, I got rid of a few unnecessary restrictions on
>> foreign tables so as to avoid introducing warts into inheritance behavior.
>> In particular, we now allow NOT VALID CHECK constraints (and hence ALTER
>> ... VALIDATE CONSTRAINT), ALTER SET STORAGE, and ALTER SET WITH/WITHOUT
>> OIDS. These are probably no-ops anyway for foreign tables, though
>> conceivably an FDW might choose to implement some behavior for STORAGE
>> or OIDs.
>
> I agree with you on this point. However, ISTM there is a bug in
> handling OIDs on foreign tables; while we now allow for ALTER SET
> WITH/WITHOUT OIDS, we still don't allow the default_with_oids parameter
> for foreign tables. I think that since CREATE FOREIGN TABLE should be
> consistent with ALTER FOREIGN TABLE, we should also allow the parameter
> for foreign tables. Attached is a patch for that.
I also updated docs. Attached is an updated version of the patch.
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-hackersAttachments:
[text/x-diff] tablecmd-v2.patch (2.2K, ../5534B6DF.5060601@lab.ntt.co.jp/2-tablecmd-v2.patch)
download | inline diff:
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***************
*** 6745,6752 **** dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
</term>
<listitem>
<para>
! This controls whether <command>CREATE TABLE</command> and
! <command>CREATE TABLE AS</command> include an OID column in
newly-created tables, if neither <literal>WITH OIDS</literal>
nor <literal>WITHOUT OIDS</literal> is specified. It also
determines whether OIDs will be included in tables created by
--- 6745,6753 ----
</term>
<listitem>
<para>
! This controls whether <command>CREATE TABLE</command>,
! <command>CREATE TABLE AS</command> and
! <command>CREATE FOREIGN TABLE</command> include an OID column in
newly-created tables, if neither <literal>WITH OIDS</literal>
nor <literal>WITHOUT OIDS</literal> is specified. It also
determines whether OIDs will be included in tables created by
*** a/doc/src/sgml/ref/create_foreign_table.sgml
--- b/doc/src/sgml/ref/create_foreign_table.sgml
***************
*** 293,298 **** CHECK ( <replaceable class="PARAMETER">expression</replaceable> )
--- 293,304 ----
responsibility to ensure that the constraint definition matches
reality.
</para>
+ + <para>+ To add OIDs to the table created by <command>CREATE FOREIGN TABLE</command>,+ enable the <xref linkend="guc-default-with-oids"> configuration+ variable.+ </para>
</refsect1>
<refsect1 id="SQL-CREATEFOREIGNTABLE-examples">
*** a/src/backend/commands/tablecmds.c
--- b/src/backend/commands/tablecmds.c
***************
*** 580,586 **** DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId,
descriptor = BuildDescForRelation(schema);
localHasOids = interpretOidsOption(stmt->options,
! (relkind == RELKIND_RELATION));
descriptor->tdhasoid = (localHasOids || parentOidCount > 0);
/*
--- 580,587 ----
descriptor = BuildDescForRelation(schema);
localHasOids = interpretOidsOption(stmt->options,
! (relkind == RELKIND_RELATION ||
! relkind == RELKIND_FOREIGN_TABLE));
descriptor->tdhasoid = (localHasOids || parentOidCount > 0);
/*
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, tgl@sss.pgh.pa.us, ashutosh.bapat@enterprisedb.com, horiguchi.kyotaro@lab.ntt.co.jp, hlinnakangas@vmware.com, noah@leadboat.com, shigeru.hanada@gmail.com
Subject: Re: inherit support for foreign tables
In-Reply-To: <5534B6DF.5060601@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