Re: 7.2 stuff - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: 7.2 stuff
Date
Msg-id GNELIHDDFBOCMGBFGEFOKEJBCAAA.chriskl@familyhealth.com.au
Whole thread Raw
In response to Re: 7.2 stuff  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: 7.2 stuff
Re: 7.2 stuff
Re: 7.2 stuff
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: TODO
Next
From: Barry Lind
Date:
Subject: Re: insert/update/delete statements returning a query response