On Tue, 2008-10-07 at 07:21 +0100, Simon Riggs wrote:
> It was an excellent question because that aspect isn't handled correctly
> in the enclosed patch for subcommands, other than index-creating
> My main focus is on these commands
> * CREATE TRIGGER
> * ALTER TABLE .. ADD PRIMARY KEY
> * ALTER TABLE .. ADD FOREIGN KEY
* CREATE RULE
> because those are the most painful ones. We could make it work against
> more, but we'd need to rewrite lots and lots of catalog update code.
OK, patch updated, tested, working.
Points of note.
1. I've left the infrastructure there for further changes, but we can
rip that out if desired.
2. Also need to decide whether we want pg_class.reltriggers as int2 (as
implemented here) or switch to relhastriggers as boolean.
3. The patch introduces a slight weirdness: if you create two FKs on the
same column at the same time you end up with two constraints with
identical names. Drop constraint then removes them both, though in other
respects they are both valid, just not uniquely. CREATE INDEX avoids
this by way of the unique index on relname. The equivalent index on
pg_constraint is not unique, though *cannot* be made unique without
breaking some corner cases of table inheritance.
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2008-10-07 12:30:57|
|Subject: Re: Reducing some DDL Locks to ShareLock|
|Previous:||From: Heikki Linnakangas||Date: 2008-10-07 11:16:06|
|Subject: Re: Weird behaviour with ALTER TABLE ... SET TABLESPACE