Message-ID: <5305DF28.1010308@lab.ntt.co.jp>
Date: Thu, 20 Feb 2014 19:55:36 +0900
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.0;
 rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
CC: shigeru.hanada@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: inherit support for foreign tables
References: <000901cf2c93$a7d67c60$f7837520$@etsuro@lab.ntt.co.jp>
	<20140219.121224.220243854.horiguchi.kyotaro@lab.ntt.co.jp>
	<53048A26.8040207@lab.ntt.co.jp>
 <20140220.154736.15628889.horiguchi.kyotaro@lab.ntt.co.jp>
In-Reply-To: <20140220.154736.15628889.horiguchi.kyotaro@lab.ntt.co.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

(2014/02/20 15:47), Kyotaro HORIGUCHI wrote:
> Although my concerns here are only two points,
> unanticipated application and "maintenancibility".  I gave a
> consideration on these issues again.

Sorry, I misunderstood what you mean by "unanticipated application".

> Then, I think it could be enough by giving feedback to operators
> for the first issue.
>
> =# ALTER TABLE parent ADD CHECK (tempmin < tempmax),
>                        ALTER tempmin SET NOT NULL,
>                        ALTER tempmin SET DEFAULT 0;
> NOTICE: Child foregn table child01 is affected.
> NOTICE: Child foregn table child02 is affected
> NOTICE: Child foregn table child03 rejected 'alter tempmin set default'
>
> What do you think about this? It looks a bit too loud for me
> though...

I think that's a good idea.  What do others think?

> Then the second issue, however I don't have enough idea of how
> ALTER TABLE works, the complexity would be reduced if acceptance
> chek for alter "action"s would done on foreign server or data
> wrapper side, not on the core of ALTER TABLE. It would also be a
> help to output error messages like above.

I'm not sure it's worth having such an mechanism inside/outside the PG 
core.  I might misunderstand your concern here, but is it the risk of 
constraint violation?  If so, I'd like to vote for an idea of avoiding 
that violation by making the FDW in itself perform ExecQual() for each 
tuple retrived from the remote server at the query time.

>> We spent a lot of time discussing this issue, and the consensus is
>> that it's users' fault if there are some tuples on the remote side
>> violating a given constraint, as mentioned in the documentation.
>
> I'm worried about not that but the changes and possible
> inconsistency would take place behind operators' backs. And this
> looks to cause such inconsistencies for me.

That is what you mean by "unanticipated application", right?

>>>> * [NO] INHERIT parent_table
>>>
>>> Is this usable for inheritance foreign children? NO INHERIT
>>> removes all foreign children but INHERIT is nop.
>>
>> I didn't express clearly.  Sorry for that.  Let me explain about it.
>>
>> * ALTER FOREIGN TABLE target_table *INHERIT* parent_table: Add the
>> * target table as a new child of the parent table.
>> * ALTER FOREIGN TABLE target_table *NO INHERIT* parent_table: Remove the
>> * target table from the list of children of the parent table.
>
> I got it, thank you. It alone seems no probmen but also doesn't
> seem to be a matter of 'ALTER TABLE'. Could you tell me how this
> is related to 'ALTER TABLE'?

These are not related to ALTER TABLE.  [NO] INHERIT parent_table (and 
ADD/DROP CONSTRAINT) are what I think should be newly allowed to apply 
to foreign tables directly.

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