Subject: BUG #3774: create table like including index doesn't update pg_constraints with primary key

From: "guillaume (ioguix) de Rorthais" <[email-masked]>
Date: Thu, 22 Nov 2007 17:47:50 GMT

The following bug has been logged online:

Bug reference:      3774
Logged by:          guillaume (ioguix) de Rorthais
Email address:      [email-masked]
PostgreSQL version: 8.3 beta3
Operating system:   mac os x 10.4.10
Description:        create table like including index doesn't update
pg_constraints with primary key
Details: 

When creating a table using the "create table ... (like ... inluding
indexes...)" syntaxe, pg_catalog.pg_constraint is not updated with the PK
constraints which actually is setted in pg_index.

Here is my test script :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pagila=# --the original table                                               
                                                                            
                                                          \d city           

  Table "public.city"
   Column    |            Type             |                       Modifiers
                       
-------------+-----------------------------+--------------------------------
------------------------
 city_id     | integer                     | not null default
nextval('city_city_id_seq'::regclass)
 city        | character varying(50)       | not null
 country_id  | smallint                    | not null
 last_update | timestamp without time zone | not null default now()
Indexes:
    "city_pkey" PRIMARY KEY, btree (city_id)
    "idx_fk_country_id" btree (country_id)
Foreign-key constraints:
    "city_country_id_fkey" FOREIGN KEY (country_id) REFERENCES
country(country_id) ON UPDATE CASCADE ON DELETE RESTRICT
Triggers:
    last_updated BEFORE UPDATE ON city FOR EACH ROW EXECUTE PROCEDURE
last_updated()

pagila=# -- its pk constraint in pg_constraint                              
                                                                            
                                                          SELECT relname,
conname, contype                                                            
                                                                            
                                          FROM pg_class cl                  

                       JOIN pg_constraint co ON (cl.oid=co.conrelid)        

    JOIN pg_namespace n ON (cl.relnamespace=n.oid)                          
                                                                            
                                                              WHERE
cl.relname='city' AND n.nspname='public' AND contype='p';
 relname |  conname  | contype 
---------+-----------+---------
 city    | city_pkey | p
(1 row)

pagila=# -- create the new table citylike like city                         
                                                                            
                                                          CREATE  TABLE
citylike (LIKE city INCLUDING INDEXES INCLUDING DEFAULTS);
CREATE TABLE
pagila=# --the citylike table                                               
                                                                            
                                                          \d citylike
                                      Table "public.citylike"
   Column    |            Type             |                       Modifiers
                       
-------------+-----------------------------+--------------------------------
------------------------
 city_id     | integer                     | not null default
nextval('city_city_id_seq'::regclass)
 city        | character varying(50)       | not null
 country_id  | smallint                    | not null
 last_update | timestamp without time zone | not null default now()
Indexes:
    "citylike_pkey" PRIMARY KEY, btree (city_id)
    "citylike_country_id_key" btree (country_id)

pagila=# -- citylike constraints'
pagila=# SELECT relname, conname, contype                                   
                                                                            
                                                                   FROM
pg_class cl                                                                 
                                                                            
                                                     JOIN pg_constraint co
ON (cl.oid=co.conrelid)                                                     
                                                                            
                                    JOIN pg_namespace n ON
(cl.relnamespace=n.oid)                                                     
                                                                            
                                   WHERE cl.relname='citylike' AND
n.nspname='public' AND contype='p';
 relname | conname | contype 
---------+---------+---------
(0 rows)

pagila=#
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'm not sure if this issue is actually a bug or if there a logic behind
this, but as the primary key is a constraint, I would expect it to be setted
in pg_constraint, shouldn't it ?

---

From: NikhilS <[email-masked]>
Date: Fri, 30 Nov 2007 13:14:53 +0530

Hi,

> in pg_constraint, shouldn't it ?

This can be handled by setting index->isconstraint appropriately inside
generateClonedIndexStmt().

The fundamental question though is should we allow primary, unique
CONSTRAINTS which use the index mechanism just as an implementation to be
created using the "INCLUDING INDEXES" mechanism.

As per the discussion here:

http://www.nabble.com/Re%3A-CREATE-TABLE-LIKE-INCLUDING-INDEXES-support-p10683716.html

maybe we should not?

In other words "INCLUDING INDEXES" should only create those indexes which do
not have isconstraint set to TRUE.

Comments?

Regards,
Nikhils
-- 
EnterpriseDB               http://www.enterprisedb.com

---

From: Tom Lane <[email-masked]>
Date: Sat, 01 Dec 2007 18:46:52 -0500

> generateClonedIndexStmt().

Done.

> created using the "INCLUDING INDEXES" mechanism.

Yeah, this bizarreness was foreseen and agreed to back when we set up
LIKE INCLUDING CONSTRAINTS the way it was defined (ie, copying only
CHECK constraints and not other things called constraints).  I was never
very thrilled with that definition myself, but it's a bit too late to
revisit it.

			regards, tom lane

---

From: NikhilS <[email-masked]>
Date: Sun, 2 Dec 2007 13:44:20 +0530

Hi,

> very thrilled with that definition myself, but it's a bit too late to

Yeah this is all confusing. I believe we should remove the following TODO
now that the above has been checked in:

 CREATE

   - Have WITH CONSTRAINTS also create constraint indexes

   http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php

Regards,
Nikhils

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 12 Dec 2007 19:34:05 -0500 (EST)

Tom, did your recent commit to clean up LIKE ... INCLUDING INDEXES fix
this?

---------------------------------------------------------------------------

guillaume (ioguix) de Rorthais wrote:
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq

-- 
  Bruce Momjian  <[email-masked]>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 6 Mar 2008 16:45:21 -0500 (EST)

Tom, did your commit to clean up LIKE ... INCLUDING INDEXES fix
this?

> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

---

From: Tom Lane <[email-masked]>
Date: Thu, 06 Mar 2008 17:20:11 -0500

> Tom, did your commit to clean up LIKE ... INCLUDING INDEXES fix

Yes, see 2007-12-01 commit.

			regards, tom lane