From: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Zeugswetter Andreas OSB sIT" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch: Add columns via CREATE OR REPLACE VIEW |
Date: | 2008-10-04 01:39:37 |
Message-ID: | 603c8f070810031839y7ce9a852o86effbab9fd6dd9b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2008-10-04 15:33:21 | CYCLE and SEARCH [was Re: Common Table Expressions (WITH RECURSIVE) patch] |
Previous Message | Tom Lane | 2008-10-03 19:55:56 | Re: Common Table Expressions (WITH RECURSIVE) patch |