Thread: 7.2 stuff
How far off is 7.2? Ages? I want to add the rest of the ALTER TABLE functionality for 7.2, but I've just been busy - don't worry I haven't forgotten! This is my personal TODO list: * ALTER TABLE ADD PRIMARY KEY- Done, except code that detects whether or not a pk already exists * ALTER TABLE ADD UNIQUE- Done, except code that detects whether or not a unique key already exists over the specified fields * PSQL - SHOW FOREIGN KEYS- Still working on a query. If I come up with a good one - would a catalog view of them be useful? * -ALTER TABLE DROP CHECK- Already committed * ALTER TABLE DROP PRIMARY KEY- Done, will need review * ALTER TABLE DROP UNIQUE- Done, will need review * ALTER TABLE DROP FOREIGN KEY- Harder than I thought :) Working on it. * Check that pgclass.relfkeys is being set correctly.- Is pgclass.relfkeys being used at the moment? * PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS- Would be nice, once the alter statements above work. * FIX 'RESTRICT' IN DROP CONSTRAINT DOCS- It would be nice to have restrict/cascade as optional keywords at the moment? At the moment, the grammar forces people to put the word 'restrict' in, even though it does nothing. * REGRESSION TESTS- For all of the above * WILDCARDS IN PG_DUMP- It would be nice to be able to dump tables via wildcards, or once schemas exist to dump an entire schema I guess. * CHECK CREATING DUPLICATE NAMED FOREIGN KEYS- I seem to be able to create duplicate named fk's, plus I think the '<unnamed>' ones should be given auto name to make dropping constraint easier... * DOCUMENT PG_TRIGGER- Doesn't seem to be in the system catalog documentation... * MOVE ALTER CODE FROM heap.c/command.c INTO alter.c- I get the feeling I'm filling up heap.c with lots of alter table crud that is beginning to need its own file? If anyone is super-interested in seeing my unposted code, feel free to ask for it. (Or better yet, wants to finish the work ;) ) Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> How far off is 7.2? Ages?
Hopefully not. I'd like to see us get back on a reasonably short
release cycle, like every six months or less --- the last couple
major release cycles have been painfully long.
So, maybe beta around Aug-Sep?
Not speaking on behalf of core here; we haven't discussed release
schedule at all yet. Just my personal $0.02.
> * Check that pgclass.relfkeys is being set correctly.
> - Is pgclass.relfkeys being used at the moment?
A quick glimpse shows not. I have a personal todo item to fix
relhaspkey, which isn't implemented either. Feel free to fix this
one if it bugs you. (Note: it might be harder than it looks; think
about race conditions when different backends are adding/dropping
keys concurrently.)
> * MOVE ALTER CODE FROM heap.c/command.c INTO alter.c
> - I get the feeling I'm filling up heap.c with lots of alter table crud
> that is beginning to need its own file?
Code beautification efforts are always worthwhile IMHO.
regards, tom lane
On Thu, 21 Jun 2001, Tom Lane wrote: > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > How far off is 7.2? Ages? > > Hopefully not. I'd like to see us get back on a reasonably short > release cycle, like every six months or less --- the last couple > major release cycles have been painfully long. > > So, maybe beta around Aug-Sep? > > Not speaking on behalf of core here; we haven't discussed release > schedule at all yet. Just my personal $0.02. That's what I was seeing/hoping for also ...
So you have at ~2 months. > How far off is 7.2? Ages? I want to add the rest of the ALTER TABLE > functionality for 7.2, but I've just been busy - don't worry I haven't > forgotten! > > This is my personal TODO list: > > * ALTER TABLE ADD PRIMARY KEY > - Done, except code that detects whether or not a pk already exists > * ALTER TABLE ADD UNIQUE > - Done, except code that detects whether or not a unique key already exists > over the specified fields > * PSQL - SHOW FOREIGN KEYS > - Still working on a query. If I come up with a good one - would a catalog > view of them be useful? > * -ALTER TABLE DROP CHECK > - Already committed > * ALTER TABLE DROP PRIMARY KEY > - Done, will need review > * ALTER TABLE DROP UNIQUE > - Done, will need review > * ALTER TABLE DROP FOREIGN KEY > - Harder than I thought :) Working on it. > * Check that pgclass.relfkeys is being set correctly. > - Is pgclass.relfkeys being used at the moment? > * PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS > - Would be nice, once the alter statements above work. > * FIX 'RESTRICT' IN DROP CONSTRAINT DOCS > - It would be nice to have restrict/cascade as optional keywords at the > moment? At the moment, the grammar forces people to put the word 'restrict' > in, even though it does nothing. > * REGRESSION TESTS > - For all of the above > * WILDCARDS IN PG_DUMP > - It would be nice to be able to dump tables via wildcards, or once schemas > exist to dump an entire schema I guess. > * CHECK CREATING DUPLICATE NAMED FOREIGN KEYS > - I seem to be able to create duplicate named fk's, plus I think the > '<unnamed>' ones should be given auto name to make dropping constraint > easier... > * DOCUMENT PG_TRIGGER > - Doesn't seem to be in the system catalog documentation... > * MOVE ALTER CODE FROM heap.c/command.c INTO alter.c > - I get the feeling I'm filling up heap.c with lots of alter table crud > that is beginning to need its own file? > > If anyone is super-interested in seeing my unposted code, feel free to ask > for it. (Or better yet, wants to finish the work ;) ) > > Chris > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
This is a nice list and all are good items. People should be able to help you if you encounter problems. > How far off is 7.2? Ages? I want to add the rest of the ALTER TABLE > functionality for 7.2, but I've just been busy - don't worry I haven't > forgotten! > > This is my personal TODO list: > > * ALTER TABLE ADD PRIMARY KEY > - Done, except code that detects whether or not a pk already exists > * ALTER TABLE ADD UNIQUE > - Done, except code that detects whether or not a unique key already exists > over the specified fields > * PSQL - SHOW FOREIGN KEYS > - Still working on a query. If I come up with a good one - would a catalog > view of them be useful? > * -ALTER TABLE DROP CHECK > - Already committed > * ALTER TABLE DROP PRIMARY KEY > - Done, will need review > * ALTER TABLE DROP UNIQUE > - Done, will need review > * ALTER TABLE DROP FOREIGN KEY > - Harder than I thought :) Working on it. > * Check that pgclass.relfkeys is being set correctly. > - Is pgclass.relfkeys being used at the moment? > * PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS > - Would be nice, once the alter statements above work. > * FIX 'RESTRICT' IN DROP CONSTRAINT DOCS > - It would be nice to have restrict/cascade as optional keywords at the > moment? At the moment, the grammar forces people to put the word 'restrict' > in, even though it does nothing. > * REGRESSION TESTS > - For all of the above > * WILDCARDS IN PG_DUMP > - It would be nice to be able to dump tables via wildcards, or once schemas > exist to dump an entire schema I guess. > * CHECK CREATING DUPLICATE NAMED FOREIGN KEYS > - I seem to be able to create duplicate named fk's, plus I think the > '<unnamed>' ones should be given auto name to make dropping constraint > easier... > * DOCUMENT PG_TRIGGER > - Doesn't seem to be in the system catalog documentation... > * MOVE ALTER CODE FROM heap.c/command.c INTO alter.c > - I get the feeling I'm filling up heap.c with lots of alter table crud > that is beginning to need its own file? > > If anyone is super-interested in seeing my unposted code, feel free to ask > for it. (Or better yet, wants to finish the work ;) ) > > Chris > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Christopher, do you want any of this added to the TODO? --------------------------------------------------------------------------- > How far off is 7.2? Ages? I want to add the rest of the ALTER TABLE > functionality for 7.2, but I've just been busy - don't worry I haven't > forgotten! > > This is my personal TODO list: > > * ALTER TABLE ADD PRIMARY KEY > - Done, except code that detects whether or not a pk already exists > * ALTER TABLE ADD UNIQUE > - Done, except code that detects whether or not a unique key already exists > over the specified fields > * PSQL - SHOW FOREIGN KEYS > - Still working on a query. If I come up with a good one - would a catalog > view of them be useful? > * -ALTER TABLE DROP CHECK > - Already committed > * ALTER TABLE DROP PRIMARY KEY > - Done, will need review > * ALTER TABLE DROP UNIQUE > - Done, will need review > * ALTER TABLE DROP FOREIGN KEY > - Harder than I thought :) Working on it. > * Check that pgclass.relfkeys is being set correctly. > - Is pgclass.relfkeys being used at the moment? > * PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS > - Would be nice, once the alter statements above work. > * FIX 'RESTRICT' IN DROP CONSTRAINT DOCS > - It would be nice to have restrict/cascade as optional keywords at the > moment? At the moment, the grammar forces people to put the word 'restrict' > in, even though it does nothing. > * REGRESSION TESTS > - For all of the above > * WILDCARDS IN PG_DUMP > - It would be nice to be able to dump tables via wildcards, or once schemas > exist to dump an entire schema I guess. > * CHECK CREATING DUPLICATE NAMED FOREIGN KEYS > - I seem to be able to create duplicate named fk's, plus I think the > '<unnamed>' ones should be given auto name to make dropping constraint > easier... > * DOCUMENT PG_TRIGGER > - Doesn't seem to be in the system catalog documentation... > * MOVE ALTER CODE FROM heap.c/command.c INTO alter.c > - I get the feeling I'm filling up heap.c with lots of alter table crud > that is beginning to need its own file? > > If anyone is super-interested in seeing my unposted code, feel free to ask > for it. (Or better yet, wants to finish the work ;) ) > > Chris > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Well, it was just a bunch of stuff I wanted to work on, feel free to add it to the TODO list. Some comments are below. > > * ALTER TABLE ADD PRIMARY KEY > > - Done, except code that detects whether or not a pk already exists > > * ALTER TABLE ADD UNIQUE > > - Done, except code that detects whether or not a unique The ADD UNIQUE stuff is in 7.2, however Tom Lane has suggested that there are some stylistic deficiencies in the code that should be improved. I won't be able to correct these before 7.2 release, as it involves me sitting down for hours searching the souce code for function definitions, figuring out how the work, etc. In fact, I'm sure a more experienced developer could perform the fixes in 10 mins... This problem is also what's stopped me submitting the ALTER TABLE / ADD PRIMARY stuff. Once the ADD UNIQUE bit is correct, ADD PRIMARY is trivial. (See: http://fts.postgresql.org/db/mw/msg.html?mid=1035632) I suggest reading the complete thread. I have fixed some of the problems in my private cvs, but no patch has been sent in... Some of the issues perhaps I should send in a patch for ASAP?? > key already exists > > over the specified fields > > * PSQL - SHOW FOREIGN KEYS > > - Still working on a query. If I come up with a good one - > would a catalog > > view of them be useful? Is there a pg_get_* function for getting foreign key definitions yet? > > * -ALTER TABLE DROP CHECK > > - Already committed Yeah, committed. > > * ALTER TABLE DROP PRIMARY KEY > > - Done, will need review > > * ALTER TABLE DROP UNIQUE > > - Done, will need review Wrote them, but they're uncommitted. Don't worry about them until 7.3. > > * ALTER TABLE DROP FOREIGN KEY > > - Harder than I thought :) Working on it. This is a toughie this one! > > * Check that pgclass.relfkeys is being set correctly. > > - Is pgclass.relfkeys being used at the moment? It looked to me that pgclass.relfkeys wasn't ever being set or updated. Is this true/correct? > > * PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS > > - Would be nice, once the alter statements above work. > > * FIX 'RESTRICT' IN DROP CONSTRAINT DOCS > > - It would be nice to have restrict/cascade as optional > keywords at the > > moment? At the moment, the grammar forces people to put the > word 'restrict' > > in, even though it does nothing. Don't bother about this - it's been documented. > > * REGRESSION TESTS > > - For all of the above I've comment a regression test for ADD UNIQUE, but I don't think the DROP CONSTRAINT stuff has a regression test yet. > > * WILDCARDS IN PG_DUMP > > - It would be nice to be able to dump tables via wildcards, > or once schemas > > exist to dump an entire schema I guess. That was just one of my little wish lists. I have a database with about a hundred tables in it and related sets of tables all share the same prefix. For instance, I would like to be able to pg_dump all the diary tables in one go. ie. pg_dump -t diary_\* audb > dump.sql Don't know if there would be widespread enough demand for this feature tho... > > * CHECK CREATING DUPLICATE NAMED FOREIGN KEYS > > - I seem to be able to create duplicate named fk's, plus I think the > > '<unnamed>' ones should be given auto name to make dropping constraint > > easier... Pretty clear. > > * DOCUMENT PG_TRIGGER > > - Doesn't seem to be in the system catalog documentation... Yeah, pg_trigger does not appear on this page: http://postgresql.planetmirror.com/devel-corner/docs/postgres/catalogs.html Thought it should be documented. I noticed this while I was doing the improvements on the contrib/fulltextindex code. > > * MOVE ALTER CODE FROM heap.c/command.c INTO alter.c > > - I get the feeling I'm filling up heap.c with lots of > alter table crud > > that is beginning to need its own file? Basically I was getting the impression that the command.c was getting big and fat and that it might be nice to split all the ALTER* commands into an alter.c or something. Tell me what I should do for 7.2... Regards, Chris
> Basically I was getting the impression that the command.c was getting big > and fat and that it might be nice to split all the ALTER* commands into an > alter.c or something. > > Tell me what I should do for 7.2... I think 7.2 is fine. We can start on 7.3 in a few weeks. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Tell me what I should do for 7.2...
At this point, none of these are on the radar screen for 7.2; we are in
"get the release out" mode, and anything that's not a critical bug fix
need not apply. But here are some comments for 7.3 and beyond.
> Is there a pg_get_* function for getting foreign key definitions yet?
No, but it seems like possibly a good idea. We should try to move away
from applications looking directly at the system catalogs, and introduce
some layer of indirection so that catalog changes don't break so many
things. pg_get_xxx functions are one approach. Peter E. has suggested
that implementing the SQL92 informational views might be a better (more
standards-compliant) way of providing that indirection. That's cool to
the extent that it works, but I wonder whether we won't find that the
SQL92 views omit important Postgres extensions. Anyway, this is a
long-term project.
> It looked to me that pgclass.relfkeys wasn't ever being set or updated. Is
> this true/correct?
I cannot find any references to it in the code, either.
> For instance, I would like to be able to pg_dump all the diary tables in one
> go.
> ie. pg_dump -t diary_\* audb > dump.sql
> Don't know if there would be widespread enough demand for this feature
> tho...
I've seen requests for that before ... and I don't think they were all
from you ;-). Seems like a reasonable wishlist item to me.
> * DOCUMENT PG_TRIGGER
> - Doesn't seem to be in the system catalog documentation...
> Yeah, pg_trigger does not appear on this page:
It's in the current sources. Perhaps you're looking at an obsolete
mirror?
> Basically I was getting the impression that the command.c was getting big
> and fat and that it might be nice to split all the ALTER* commands into an
> alter.c or something.
Cool with me. We often fail to spend enough effort on code
beautification projects; that hurts the maintainability of the project
in the long run. Feel free to devise and implement a better division
of the ALTER code. (And as I think we already talked about, it'd also
be cool to try to merge the common infrastructure of the ALTER commands
somehow. I don't like umpteen copied-and-pasted versions of the same
code, either ...)
regards, tom lane
At 23:21 26/11/01 -0500, Tom Lane wrote: > >> For instance, I would like to be able to pg_dump all the diary tables in one >> go. >> ie. pg_dump -t diary_\* audb > dump.sql >> Don't know if there would be widespread enough demand for this feature >> tho... > >I've seen requests for that before ... and I don't think they were all >from you ;-). Seems like a reasonable wishlist item to me. > I have been sent patches for this kind of thing, but I would like to see them generalized to some extent. Not sure of the syntax, but I'd like to be able to dump *any* selected pg_dump TOC entry type by name, or partial name match. ie. tables, functions, indexes, etc. Any suggestions as to how this is best done within unix-like commands? eg. pg_dump/restore --select=table:<regexp> ? pg_dump/restore --select=index:<regexp> ? Any ideas? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
In article <17242.1006834868@sss.pgh.pa.us>, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: >> Basically I was getting the impression that the command.c was getting >> big and fat and that it might be nice to split all the ALTER* commands >> into an alter.c or something. > > Cool with me. We often fail to spend enough effort on code > beautification projects; that hurts the maintainability of the project > in the long run. Feel free to devise and implement a better division of > the ALTER code. (And as I think we already talked about, it'd also be > cool to try to merge the common infrastructure of the ALTER commands > somehow. I don't like umpteen copied-and-pasted versions of the same > code, either ...) > I'd started a little of this with my TOAST slicing patch -moving some common code around in command.c (standard permissions checking and recursing over children) to eliminate duplicates. I'm still sitting on the patch and maintaining separately because it is for 7.3, but I am quite interested in some further tidying, but I don't want to load too much into a single patch. Regards John -- John Gray Azuli IT http://www.azuli.co.uk +44 121 693 3397 jgray@azuli.co.uk
Are there any TODO items here? --------------------------------------------------------------------------- Christopher Kings-Lynne wrote: > Well, it was just a bunch of stuff I wanted to work on, feel free to add it > to the TODO list. Some comments are below. > > > > * ALTER TABLE ADD PRIMARY KEY > > > - Done, except code that detects whether or not a pk already exists > > > * ALTER TABLE ADD UNIQUE > > > - Done, except code that detects whether or not a unique > > The ADD UNIQUE stuff is in 7.2, however Tom Lane has suggested that there > are some stylistic deficiencies in the code that should be improved. I > won't be able to correct these before 7.2 release, as it involves me sitting > down for hours searching the souce code for function definitions, figuring > out how the work, etc. In fact, I'm sure a more experienced developer could > perform the fixes in 10 mins... > > This problem is also what's stopped me submitting the ALTER TABLE / ADD > PRIMARY stuff. Once the ADD UNIQUE bit is correct, ADD PRIMARY is trivial. > > (See: http://fts.postgresql.org/db/mw/msg.html?mid=1035632) I suggest > reading the complete thread. I have fixed some of the problems in my > private cvs, but no patch has been sent in... > > Some of the issues perhaps I should send in a patch for ASAP?? > > > key already exists > > > over the specified fields > > > * PSQL - SHOW FOREIGN KEYS > > > - Still working on a query. If I come up with a good one - > > would a catalog > > > view of them be useful? > > Is there a pg_get_* function for getting foreign key definitions yet? > > > > * -ALTER TABLE DROP CHECK > > > - Already committed > > Yeah, committed. > > > > * ALTER TABLE DROP PRIMARY KEY > > > - Done, will need review > > > * ALTER TABLE DROP UNIQUE > > > - Done, will need review > > Wrote them, but they're uncommitted. Don't worry about them until 7.3. > > > > * ALTER TABLE DROP FOREIGN KEY > > > - Harder than I thought :) Working on it. > > This is a toughie this one! > > > > * Check that pgclass.relfkeys is being set correctly. > > > - Is pgclass.relfkeys being used at the moment? > > It looked to me that pgclass.relfkeys wasn't ever being set or updated. Is > this true/correct? > > > > * PG_DUMP DUMP CONSTRAINTS AS ALTER TABLE STATEMENTS > > > - Would be nice, once the alter statements above work. > > > * FIX 'RESTRICT' IN DROP CONSTRAINT DOCS > > > - It would be nice to have restrict/cascade as optional > > keywords at the > > > moment? At the moment, the grammar forces people to put the > > word 'restrict' > > > in, even though it does nothing. > > Don't bother about this - it's been documented. > > > > * REGRESSION TESTS > > > - For all of the above > > I've comment a regression test for ADD UNIQUE, but I don't think the DROP > CONSTRAINT stuff has a regression test yet. > > > > * WILDCARDS IN PG_DUMP > > > - It would be nice to be able to dump tables via wildcards, > > or once schemas > > > exist to dump an entire schema I guess. > > That was just one of my little wish lists. I have a database with about a > hundred tables in it and related sets of tables all share the same prefix. > For instance, I would like to be able to pg_dump all the diary tables in one > go. > > ie. pg_dump -t diary_\* audb > dump.sql > > Don't know if there would be widespread enough demand for this feature > tho... > > > > * CHECK CREATING DUPLICATE NAMED FOREIGN KEYS > > > - I seem to be able to create duplicate named fk's, plus I think the > > > '<unnamed>' ones should be given auto name to make dropping constraint > > > easier... > > Pretty clear. > > > > * DOCUMENT PG_TRIGGER > > > - Doesn't seem to be in the system catalog documentation... > > Yeah, pg_trigger does not appear on this page: > > http://postgresql.planetmirror.com/devel-corner/docs/postgres/catalogs.html > > Thought it should be documented. I noticed this while I was doing the > improvements on the contrib/fulltextindex code. > > > > * MOVE ALTER CODE FROM heap.c/command.c INTO alter.c > > > - I get the feeling I'm filling up heap.c with lots of > > alter table crud > > > that is beginning to need its own file? > > Basically I was getting the impression that the command.c was getting big > and fat and that it might be nice to split all the ALTER* commands into an > alter.c or something. > > Tell me what I should do for 7.2... > > Regards, > > Chris > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Reminder that code cleanup can be done in commands/*. --------------------------------------------------------------------------- Tom Lane wrote: > > Basically I was getting the impression that the command.c was getting big > > and fat and that it might be nice to split all the ALTER* commands into an > > alter.c or something. > > Cool with me. We often fail to spend enough effort on code > beautification projects; that hurts the maintainability of the project > in the long run. Feel free to devise and implement a better division > of the ALTER code. (And as I think we already talked about, it'd also > be cool to try to merge the common infrastructure of the ALTER commands > somehow. I don't like umpteen copied-and-pasted versions of the same > code, either ...) > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Hi, Tom - there's a comment for you further down... > > This problem is also what's stopped me submitting the ALTER TABLE / ADD > > PRIMARY stuff. Once the ADD UNIQUE bit is correct, ADD PRIMARY > is trivial. > > > > (See: http://fts.postgresql.org/db/mw/msg.html?mid=1035632) I suggest > > reading the complete thread. I have fixed some of the problems in my > > private cvs, but no patch has been sent in... > > > > Some of the issues perhaps I should send in a patch for ASAP?? All of the above is a non-issue - it was implemented by tom in the parser, and my code was removed. Howver, add primary key needs a regression test. > > > key already exists > > > > over the specified fields > > > > * PSQL - SHOW FOREIGN KEYS > > > > - Still working on a query. If I come up with a good one - > > > would a catalog > > > > view of them be useful? > > > > Is there a pg_get_* function for getting foreign key definitions yet? I still want to do the above - however Stephen Sazbo has ideas about changing all the fk stuff... > > > > * -ALTER TABLE DROP CHECK > > > > - Already committed > > > > Yeah, committed. Committed - it needs a regression test tho. > > > > * ALTER TABLE DROP PRIMARY KEY > > > > - Done, will need review > > > > * ALTER TABLE DROP UNIQUE > > > > - Done, will need review > > > > Wrote them, but they're uncommitted. Don't worry about them until 7.3. 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??? > > > > * ALTER TABLE DROP FOREIGN KEY > > > > - Harder than I thought :) Working on it. > > > > This is a toughie this one! And also depends on future fk changes. > > > > * Check that pgclass.relfkeys is being set correctly. > > > > - Is pgclass.relfkeys being used at the moment? > > > > It looked to me that pgclass.relfkeys wasn't ever being set or > updated. Is > > this true/correct? Correct. > > > > * WILDCARDS IN PG_DUMP > > > > - It would be nice to be able to dump tables via wildcards, > > > or once schemas > > > > exist to dump an entire schema I guess. > > > > That was just one of my little wish lists. I have a database > with about a > > hundred tables in it and related sets of tables all share the > same prefix. > > For instance, I would like to be able to pg_dump all the diary > tables in one > > go. > > > > ie. pg_dump -t diary_\* audb > dump.sql > > > > Don't know if there would be widespread enough demand for this feature > > tho... The above would be a nice feature... > > > > * CHECK CREATING DUPLICATE NAMED FOREIGN KEYS > > > > - I seem to be able to create duplicate named fk's, > plus I think the > > > > '<unnamed>' ones should be given auto name to make dropping > constraint > > > > easier... > > Pretty clear. Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.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
On Sun, 24 Feb 2002, Tom Lane wrote: > "Christopher Kings-Lynne" <chriskl@familyhealth.com.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? Apart from the fact that currently pkeys don't inherit, does it make sense that the child can have a separate primary key since it should really be inheriting from the parent and you can't have two, right?
On Mon, 2002-02-25 at 07:53, Tom Lane wrote: > "Christopher Kings-Lynne" <chriskl@familyhealth.com.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? Probably not as the primary key is currently not inherited when doing create. ------------ Hannu
On Mon, 2002-02-25 at 07:44, Christopher Kings-Lynne wrote: > > > > > key already exists > > > > > over the specified fields > > > > > * PSQL - SHOW FOREIGN KEYS > > > > > - Still working on a query. If I come up with a good one - > > > > would a catalog > > > > > view of them be useful? > > > > > > Is there a pg_get_* function for getting foreign key definitions yet? > > I still want to do the above - however Stephen Sazbo has ideas about > changing all the fk stuff... That makes it almost mandatory - how else will we be able to dump/reload fk's for the new fk implementation? --------- Hannu