Re: [BUGS] Running queries on inherited tables

Michael Richards <miker(at)scifair(dot)acadiau(dot)ca> writes:
> On Sun, 12 Sep 1999, Tom Lane wrote:
>> That would be a good route to a reimplementation, actually. Want to
>> have a go at it?
> Sure. I'll wade into the code and see if I can swim. I think I'll first
> try to implement ALTER TABLE class_name DELETE COLUMN col_name

> Which version do you suggest I work with to come up with patches?

You should definitely start from current sources, not from REL6_5,
in order to minimize the pain of integrating changes. The tricky call
here is how often to update your copy of current --- rebuilding every
day is just a time sink, but if you let your copy get too far out of
date then you have problems merging what you've done. One possibility
is to keep an eye on the cvs-committers digest, and update(+ merge
changes) whenever someone commits changes in the same files that you've
got changes to.

> D'oh. Now that I think about it you'd need 2n the amount of space
> anyway... That brings up an intersting point... Does the database do a
> rollback if it runs out of space on the device?

I think it rolls back OK if we fail to acquire a new page for a user
table. Failing to write a pg_log page might be disastrous though.
Vadim would understand that better than I do.

regards, tom lane