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

Re: patch: Add columns via CREATE OR REPLACE VIEW

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch: Add columns via CREATE OR REPLACE VIEW
Date: 2008-08-07 15:43:53
Message-ID: 10395.1218123833@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Robert Haas escribi:
>> Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
>> to an existing view.

> What happens with the columns previously defined?  What happens if I
> specify a different column definition for them; does it raise an error?

The original idea here was to give REPLACE VIEW as much flexibility
as we've recently added for tables via ALTER TABLE, which would ideally
include

1. adding columns
2. renaming columns
3. dropping columns that are not referenced elsewhere
4. changing type of columns that are not referenced elsewhere

But it seems hard to tell the difference between a "rename" and a
"drop".  I think that we aren't going to get far on this until we
decide what we will consider to be the identity of a view column.
With regular tables the attnum is a persistent identifier, but that
doesn't seem to play nicely for REPLACE VIEW, at least not if you're
wanting to allow people to remove columns from their view definitions.

Maybe the right way is to *not* use CREATE OR REPLACE VIEW, but
rather ALTER VIEW ADD COLUMN and so on.  Then column identity seems
a lot easier to keep track of.

Thoughts?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2008-08-07 15:44:52
Subject: Re: Parsing of pg_hba.conf and authenticationinconsistencies
Previous:From: Robert HaasDate: 2008-08-07 15:42:49
Subject: Re: patch: Add columns via CREATE OR REPLACE VIEW

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