Re: Beta time

From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Beta time
Date: 2001-09-19 03:07:32
Message-ID: ECEHIKNFIMMECLEBJFIGAEPGCBAA.chriskl@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Attached is the CONSTR_PRIMARY switch block from command.c. I've marked the
problem test with '@@'.

Basically the patch all seems to work properly, except that it doesn't
recognise existing primarty keys. ie. You can go ALTER TABLE test ADD
PRIMARY KEY(a) multiple times and it will keep adding a primary key. My ADD
UNIQUE patch that has been committed is virtually identical, and has no such
problem.

Chris

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Tuesday, 18 September 2001 12:41 PM
> To: Christopher Kings-Lynne
> Cc: Bruce Momjian; PostgreSQL-development
> Subject: Re: [HACKERS] Beta time
>
>
> "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> > I am checking the indexStruct->indisprimary field, but it
> always resolves to
> > false. indisunique works fine. It is a trivial change to the
> ADD UNIQUE
> > code, but it doesn't work. Viewing the system catalogs and
> '\d' both show
> > the indices as primary, but the SearchSysCache funtion believes
> that they
> > are not.
>
> Doesn't make any sense to me either. Want to post your code?
>
> regards, tom lane
>

Attachment Content-Type Size
command.c application/octet-stream 7.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-09-19 04:14:34 Re: x = NULL
Previous Message Barry Lind 2001-09-19 02:30:26 Re: slow UNIONing