Re: [HACKERS] [PATCHES] ALTER TABLE modifications
-- moving to -hackers > Do you have special cases for type changes which don't need data > transforms. > I mean things like changing VARCHAR(10) to VARCHAR(20), dropping the NOT > NULL constraint or changing CHECK A < 3 to CHECK A < 4. There are basically 3 types of change. The first is simple, a removal. These do not kick off scans of any form. You simply do not add any work to the post-processing queue. The second requests a table scan. This is intended for check constraint, etc. additions. The third is a rewrite of the records which is done with via a file swap. All type changes, column + default additions, etc. are done this way. It will simultaneously take care of the check constraint, etc. requests as well. > All these could be done with no data migration or extra checking. I'll leave it for someone else to add in the queue bypasses for simple items. I've otherwise attempted to maintain the current processes (new check constraint always scans, etc.). Queued foreign keys are going to need to work a little differently since they are cross table checks. I'm currently deferring them until everything else has been accomplished (affects alter type only at the moment). ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] ALTER TABLE modifications
Hannu Krosing writes: > > AFAICT, this patch does not buy us anything at all. It's just a different > > spelling of existing functionality. We have never done that before. > > what about DROP COLUMN - this is also just a different spelling for > > SELECT INTO, migrate all constraints, DROP OLD TABLE, RENAME. No, because DROP COLUMN preserves dependent objects. > > We cannot possibly leave this patch as is. People expect in-place column > > changes. > > Does SQL spec even require that SELECT * always returns columns in the > same order ? Yes: b) Otherwise, the "*" is equivalent to a sequence in which each is a column reference that references a column of T and each column of T is referenced exactly once. The columns are referenced in the ascending sequence of their ordinal position within T. > I don't think that relational model assigns any 'order' to columns. Correct, but SQL is not the relational model or vice versa. > BTW, SELECT * is just a different spelling of existing functionality ;) No, there is no other way to get a complete list of columns. (Hard-coding does not count.) -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
