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: 603c8f070810031839y7ce9a852o86effbab9fd6dd9b@mail.gmail.com (view raw or flat)
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

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-2014 The PostgreSQL Global Development Group