I'm just getting back around to this now. I guess I'm wondering if someone could advise me on the best way of getting closer to a committable patch.
The original patch just allows additional columns to be appended to the previous column list (while disallowing all other sorts of changes, including reordering/renaming/dropping columns). Although I understand that reordering, renaming, and dropping columns are potential sources of ambiguity, I don't think there is any possible ambiguity in adding columns. If so, perhaps this patch or a similar one might committable. But if not, then I'd like some suggestions on what could be done to pave the way for a future patch that would allow a more powerful version of CREATE OR REPLACE VIEW. Do I need to implement the three-tiered structure that Tom first proposed here? http://archives.postgresql.org/pgsql-hackers/2006-12/msg00977.php The major problem I have with this idea is that it seems to require us to do everything to do anything. Separating storage location from permanent ID is a performance enhancement which will probably require quite a bit of testing and discussion to figure out how it ought to work and how much control users ought to have over the behavior, questions which were extensively discussed here: http://archives.postgresql.org/pgsql-hackers/2007-02/msg01164.php On the other hand, separating permanent ID from view position requires working out the semantics of operations that rely on the column ordering, such as SELECT *, COPY, INSERT without column list, CREATE OR REPLACE VIEW view_name (column_alias, ...), and SELECT ... FROM table (column_alias, ...) as well as figuring out what sorts of DDL commands should be added to manipulate the view position. Trying to implement both of these things as a single patch sounds like it might be trying to do too much, but I'm open to suggestions. I think there would be a lot of benefit in being able to make changes to views without needing to drop and recreate all the dependent objects - it would certainly simplify things for me, and I imagine for others as well. I need some guidance though on where to go with it. I'd also be interested in knowing if anyone else is working on anything along these lines. Thanks, ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
