Re: Declarative partitioning - another take

Поиск
Список
Период
Сортировка
От alvherre@alvh.no-ip.org
Тема Re: Declarative partitioning - another take
Дата
Msg-id 731eb99b111bab73383c2115cf26c29c@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: Declarative partitioning - another take  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: Declarative partitioning - another take
Список pgsql-hackers
El 2016-10-28 07:53, Amit Langote escribió:

> @@ -6267,6 +6416,12 @@ ATAddForeignKeyConstraint(AlteredTableInfo *tab, 
> Relation rel,
>       * Validity checks (permission checks wait till we have the column
>       * numbers)
>       */
> +    if (pkrel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
> +        ereport(ERROR,
> +                (errcode(ERRCODE_WRONG_OBJECT_TYPE),
> +                 errmsg("cannot reference relation \"%s\"", 
> RelationGetRelationName(pkrel)),
> +                 errdetail("Referencing partitioned tables in foreign key 
> constraints is not supported.")));

Is there a plan for fixing this particular limitation?  It's a pretty 
serious problem for users,
and the suggested workaround (to create a separate non-partitioned table 
which carries only the PK
columns which is updated by triggers, and direct the FKs to it instead 
of to the partitioned table)
is not only a very ugly one, but also very slow.



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

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Danger of automatic connection reset in psql
Следующее
От: Abbas Butt
Дата:
Сообщение: Re: Using a latch between a background worker process and a thread