Re: BUG #9606: pg_class relhaspkey column not updated on removal of primary key
От | Venkata Balaji Nagothi |
---|---|
Тема | Re: BUG #9606: pg_class relhaspkey column not updated on removal of primary key |
Дата | |
Msg-id | CAHBAh5sd9BK=7qfjTDYBLSAtBh78rtnMSaGFoyfOb2S29FDxoQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #9606: pg_class relhaspkey column not updated on removal of primary key (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #9606: pg_class relhaspkey column not updated on removal of
primary key
|
Список | pgsql-bugs |
On Tue, Mar 18, 2014 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Jeff Frost <jeff@pgexperts.com> writes: > > Interestingly, on 9.1.11, I have a table where the pkey was added after > the fact, then dropped, but it still shows as relhaspkey even though I > manually vacuumed it: > > IIRC, VACUUM only clears relhaspkey if there are *no* indexes left --- it > doesn't bother to check whether there's one calling itself indisprimary. > We could possibly change that but it's not clear that it's worth any > effort, given that the column would still have to be defined the same > way. Apologies if i am jumping into the conversation. Technically, there is no harm or it does not make any big impact if "relhaspkey" column shows "t" even after the column has primary key constraint disabled. Logically, the information in pg_class table can be mis-leading when the column is not behaving like a traditional "primary key column". I think, It is important that, the information showing up in the "relhaspkey" column must be based on the "primary key constraint" existence rather than the "Index existence". Regards, Venkata Balaji N Sr. Database Administrator Fujitsu Australia
В списке pgsql-bugs по дате отправления: