Re: inherit support for foreign tables

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: inherit support for foreign tables
Дата
Msg-id 5305DF28.1010308@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: inherit support for foreign tables  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: inherit support for foreign tables  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Re: inherit support for foreign tables  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
(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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [bug fix] pg_ctl fails with config-only directory
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Priority table or Cache table