From: | David Virebayre <david(at)robbez(dot)com> |
---|---|
To: | Euler Taveira <euler(at)eulerto(dot)com> |
Cc: | pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Clarification regarding CREATE TABLE LIKE and FOREIGN KEYS |
Date: | 2023-12-01 12:08:15 |
Message-ID: | CAMOYa7m-VzvS9YxoOwhvsJOXLF3qS=dzGNc1N_9AJqFa0X9Pjg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
Le mer. 29 nov. 2023 à 16:24, Euler Taveira <euler(at)eulerto(dot)com> a écrit :
> On Mon, Nov 27, 2023, at 12:05 PM, PG Doc comments form wrote:
>
> It is not clear to me that foreign keys are copied or not when duplicating
> a
> table using CREATE TABLE ... LIKE ... INCLUDING ALL. I had to actually
> test
> to check what it does.
>
>
> It is impractical to add what a feature *does not* provide in general. The
> probability that that information will be obsolete (due to new features)
> is
> high. If the information is missing that's because it is not supported.
> (Of
> course, it can be an omission and, in this case, we need to fix it.)
>
"INCLUDING ALL" leads people to believe *everything* is copied.
The fact that it doesn't seem counter intuitive, at least to me.
Therefore, it doesn't seem absurd to me to warn people about what is not
copied.
I wrote the original message hoping to help improve the documentation. I
could write a draft if I'm allowed to.
I do believe that clarifying this point improves the documentation. If
there's a consensus that it doesn't, my apologies for the annoyance.
Cheers.
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2023-12-01 13:19:46 | Re: Postgres Partitions Limitations (5.11.2.3) |
Previous Message | Peter Eisentraut | 2023-12-01 07:53:50 | Re: INFORMATION_SCHEMA.routine_column_usage |