Re: 7.2 stuff

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.2 stuff
Date: 2002-02-25 02:53:41
Message-ID: 14553.1014605621@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> * ALTER TABLE DROP PRIMARY KEY
> - Done, will need review
> * ALTER TABLE DROP UNIQUE
> - Done, will need review

> I'll dredge this up again if I can. All it does is add a standards
> compliant alternative syntax for dropping those constraints. Tom - can you
> just do this in the parser, like you did it for the ADD constraints???

I don't foresee it falling out of other parser work, if that's what you
mean. If you want it done in the parser you'll have to do it yourself.

There are some semantic issues, eg: what does it mean to do ALTER TABLE
DROP PRIMARY KEY in an inheritance hierarchy? Does every child lose its
primary key (if any), even if it's not inherited from the parent?
I could see doing the "where's the primary key" lookup either at
execution time (separately for each table) or at parse time (lookup once
at the parent table) depending on which behavior you want.

regards, tom lane

In response to

  • Re: 7.2 stuff at 2002-02-25 02:44:12 from Christopher Kings-Lynne

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-02-25 02:58:52 Re: [HACKERS] Updated TODO item
Previous Message Bruce Momjian 2002-02-25 02:52:04 Re: [HACKERS] Updated TODO item