Skip site navigation (1) Skip section navigation (2)

Re: patch: Add columns via CREATE OR REPLACE VIEW

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: (view raw, whole thread or download thread mbox)
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?

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:

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.



In response to

pgsql-hackers by date

Next:From: David FetterDate: 2008-10-04 15:33:21
Subject: CYCLE and SEARCH [was Re: Common Table Expressions (WITHRECURSIVE) patch]
Previous:From: Tom LaneDate: 2008-10-03 19:55:56
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group