simple code cleanups
Hi,
I was taking a look at making ALTER TABLE ... RENAME work with
referential integrity constraints. While doing so, I cleaned up a few
spots of code along the way (mostly just adding 'const' qualifiers to
char* params) -- only the change in rename.c is slightly noteworthy.
Unless anyone sees any problems, please apply for 7.3.
As for the ALTER TABLE ... RENAME stuff, I gave up for the moment --
next I think I'm going to try changing the referential integrity code to
use oids rather than relation names, so that should kill 2 birds with
one stone (since changing RI to use OIDs is also on the TODO list, and
the OID doesn't change when a relation or attribute is renamed).
Suggestions/advice are welcome.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
Attachments:
code_cleanup.patchtext/x-patch; charset=ISO-8859-1Download+62-68
On 19 Feb 2002, Neil Conway wrote:
I was taking a look at making ALTER TABLE ... RENAME work with
referential integrity constraints. While doing so, I cleaned up a few
spots of code along the way (mostly just adding 'const' qualifiers to
char* params) -- only the change in rename.c is slightly noteworthy.
Unless anyone sees any problems, please apply for 7.3.As for the ALTER TABLE ... RENAME stuff, I gave up for the moment --
next I think I'm going to try changing the referential integrity code to
use oids rather than relation names, so that should kill 2 birds with
one stone (since changing RI to use OIDs is also on the TODO list, and
the OID doesn't change when a relation or attribute is renamed).
Suggestions/advice are welcome.
You have to be careful about changing the RI constraints to use oids
because you'll need to support restores from systems where the constraint
was dumped with names, so you can't simply make it take oids only. In
addition, the triggers should probably take attnos for the attributes
rather than names. I'd been figuring on making new functions that took
oids/attnos and changing dumping so that over time the old functions would
eventually stop being used (such as using alter table to dump the
constraints) and internally have the old functions end up being wrappers
around the new ones.
I'd been planning to start doing a bunch of work on the trigger functions
now that 7.3 development's started. I was hoping to put together a high
level plan of attack for hackers this week to see what the response was.
On Tue, 2002-02-19 at 21:19, Stephan Szabo wrote:
You have to be careful about changing the RI constraints to use oids
because you'll need to support restores from systems where the constraint
was dumped with names, so you can't simply make it take oids only. In
addition, the triggers should probably take attnos for the attributes
rather than names. I'd been figuring on making new functions that took
oids/attnos and changing dumping so that over time the old functions would
eventually stop being used (such as using alter table to dump the
constraints) and internally have the old functions end up being wrappers
around the new ones.
Ah, I see. This is more complicated than I originally thought...
I'd been planning to start doing a bunch of work on the trigger functions
now that 7.3 development's started. I was hoping to put together a high
level plan of attack for hackers this week to see what the response was.
I'm happy to leave this to you; I'll wait for the plan on -hackers and
see if I can lend a hand then.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
On Tue, 2002-02-19 at 20:40, Neil Conway wrote:
Hi,
I was taking a look at making ALTER TABLE ... RENAME work with
referential integrity constraints. While doing so, I cleaned up a few
spots of code along the way (mostly just adding 'const' qualifiers to
char* params) -- only the change in rename.c is slightly noteworthy.
Unless anyone sees any problems, please apply for 7.3.
My previous patch was only half-baked, due to the bizarre situation I
had managed to get my local source tree into. Sorry, sleep deprivation
on my part ;-)
The attached patch should work; it's made via 'cvs diff -c', so please
ignore the ugly headers CVS inserts, and apply with '-p0'.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
Attachments:
code_cleanup-2.patchtext/plain; charset=ISO-8859-1Download+76-85
This has been saved for the 7.3 release:
http://candle.pha.pa.us/cgi-bin/pgpatches2
---------------------------------------------------------------------------
Neil Conway wrote:
On Tue, 2002-02-19 at 20:40, Neil Conway wrote:
Hi,
I was taking a look at making ALTER TABLE ... RENAME work with
referential integrity constraints. While doing so, I cleaned up a few
spots of code along the way (mostly just adding 'const' qualifiers to
char* params) -- only the change in rename.c is slightly noteworthy.
Unless anyone sees any problems, please apply for 7.3.My previous patch was only half-baked, due to the bizarre situation I
had managed to get my local source tree into. Sorry, sleep deprivation
on my part ;-)The attached patch should work; it's made via 'cvs diff -c', so please
ignore the ugly headers CVS inserts, and apply with '-p0'.Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
---------------------------(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, Pennsylvania 19026
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Neil Conway wrote:
On Tue, 2002-02-19 at 20:40, Neil Conway wrote:
Hi,
I was taking a look at making ALTER TABLE ... RENAME work with
referential integrity constraints. While doing so, I cleaned up a few
spots of code along the way (mostly just adding 'const' qualifiers to
char* params) -- only the change in rename.c is slightly noteworthy.
Unless anyone sees any problems, please apply for 7.3.My previous patch was only half-baked, due to the bizarre situation I
had managed to get my local source tree into. Sorry, sleep deprivation
on my part ;-)The attached patch should work; it's made via 'cvs diff -c', so please
ignore the ugly headers CVS inserts, and apply with '-p0'.Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
---------------------------(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, Pennsylvania 19026
It appears this has mostly been applied. Would you please resubmit
based on current CVS any pieces that may be missing? Thanks.
---------------------------------------------------------------------------
Neil Conway wrote:
On Tue, 2002-02-19 at 20:40, Neil Conway wrote:
Hi,
I was taking a look at making ALTER TABLE ... RENAME work with
referential integrity constraints. While doing so, I cleaned up a few
spots of code along the way (mostly just adding 'const' qualifiers to
char* params) -- only the change in rename.c is slightly noteworthy.
Unless anyone sees any problems, please apply for 7.3.My previous patch was only half-baked, due to the bizarre situation I
had managed to get my local source tree into. Sorry, sleep deprivation
on my part ;-)The attached patch should work; it's made via 'cvs diff -c', so please
ignore the ugly headers CVS inserts, and apply with '-p0'.Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
---------------------------(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, Pennsylvania 19026