Re: On partitioning, PKs and FKs

From: Ron <ronljohnsonjr(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: On partitioning, PKs and FKs
Date: 2021-07-08 20:09:56
Message-ID: 03b166e9-ef78-ee62-3e5f-27a45fa7debb@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

The docs are pretty clear that all constraints must have the partition key
as part of the key, and PK is most certainly a constraint.

I welcome a counter-example.

On 7/8/21 10:23 AM, Alban Hertroys wrote:
> On 2021-07-08 13:30, Ron wrote:
> > Thus, the bigTable PK must be on id, columnX, (No, I don't like it
> > either.)
>
> That's not entirely true. You can keep the PK on id if you additionally
> create a unique constraint on (id, columnX).
>
> That way, you can at least be certain that the uniqueness of the PK
> remains in-tact, even if that is a surrogate key that has nothing to do
> with the uniqueness of the actual records.
>
> Regards,
>
> Alban Hertroys.
>
>
> *Alban Hertroys***
>
>
>
> Apollo Tyres (NL) B.V.
> Ir. E.L.C. Schiffstraat 370, 7547 RD Enschede, The Netherlands
> +31 (0)53 4888 776
>
> alban(dot)hertroys(at)apollotyres(dot)com
> Chamber of Commerce number: 34223268
>
> CIN: L25111KL1972PLC002449
>
> Registered Office: Apollo Tyres Ltd, 3rd Floor, Areekal Mansion, Panampilly Nagar, Kochi 682036, India
>
>
>
> Disclaimer:
>
> The information contained in this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the contents of this information is strictly prohibited and may be unlawful and request you to delete this message and any attachments and advise the sender by return e-mail. The confidentiality of this message is not warranted. Apollo Tyres and its subsidiaries rule out any and every liability resulting from this or any other electronic transmiss
>

--
Angular momentum makes the world go 'round.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2021-07-08 20:19:11 Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works
Previous Message Tom Lane 2021-07-08 20:09:02 Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works