Re: 7.2 stuff - Mailing list pgsql-hackers

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