Re: Declarative partitioning - another take - Mailing list pgsql-hackers

From alvherre@alvh.no-ip.org
Subject Re: Declarative partitioning - another take
Date
Msg-id 731eb99b111bab73383c2115cf26c29c@alvh.no-ip.org
Whole thread Raw
In response to Re: Declarative partitioning - another take  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Declarative partitioning - another take
List 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 by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Danger of automatic connection reset in psql
Next
From: Abbas Butt
Date:
Subject: Re: Using a latch between a background worker process and a thread