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
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 |