Thank you for your reply.
I understand that getting the primary key as xxx_pkey , while I
expected pk_xxx, is not a bug, it's a feature.
However I insist about foreign keys: source table is present with 13
rows in information_schema.key_column_usage,
while destination table only has one.
To provide a complete example, I must "sanitize" the names which are
linked to the product I am working on. It will take some time.
There are ten single-column foreign keys, one three-column foreign key.
Primary key is single-column, numeric, named "oid".
Kind regards
Massimo Roscio
On 29/09/16 14:59, Tom Lane wrote:
> mroscio@tin.it writes:
>> When yyy has no primary keys, all constraints are duly created on xxx.
>> When yyy has a primary key named pk_yyy, a primary key named xxx_pkey is
>> created, all other constraints are lost.
> Works for me ...
>
> regression=# create table yyy (f1 int constraint pk_yyy primary key, f2 int unique);
> CREATE TABLE
> regression=# \d yyy
> Table "public.yyy"
> Column | Type | Modifiers
> --------+---------+-----------
> f1 | integer | not null
> f2 | integer |
> Indexes:
> "pk_yyy" PRIMARY KEY, btree (f1)
> "yyy_f2_key" UNIQUE CONSTRAINT, btree (f2)
>
> regression=# create table xxx (like yyy including all);
> CREATE TABLE
> regression=# \d xxx
> Table "public.xxx"
> Column | Type | Modifiers
> --------+---------+-----------
> f1 | integer | not null
> f2 | integer |
> Indexes:
> "xxx_pkey" PRIMARY KEY, btree (f1)
> "xxx_f2_key" UNIQUE CONSTRAINT, btree (f2)
>
>
> regards, tom lane
>