Re: patch: Add columns via CREATE OR REPLACE VIEW - Mailing list pgsql-hackers

From Tom Lane
Subject Re: patch: Add columns via CREATE OR REPLACE VIEW
Date
Msg-id 29680.1218153378@sss.pgh.pa.us
Whole thread Raw
In response to Re: patch: Add columns via CREATE OR REPLACE VIEW  ("Robert Haas" <robertmhaas@gmail.com>)
Responses Re: patch: Add columns via CREATE OR REPLACE VIEW  ("Robert Haas" <robertmhaas@gmail.com>)
List pgsql-hackers
"Robert Haas" <robertmhaas@gmail.com> writes:
> On Thu, Aug 7, 2008 at 5:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Because it sidesteps the problem of tracking which column is supposed to
>> be which.  If you try to do it through CREATE OR REPLACE VIEW, you have
>> to either be extremely restrictive (like probably not allow renaming
>> of columns at all), or write some AI-complete algorithm to guess at what
>> the user intended.

> The current code takes the approach of being extremely restrictive -
> it doesn't let you change anything at all.  The code I'm proposing
> manages to relax that restriction without creating any ambiguity that
> anyone has been able to point out.  All of the ambiguities that have
> been mentioned are problems that might be created by some other,
> entirely hypothetical patch.

Well, my feeling is that if we are inventing a new feature we ought not
paint ourselves into a corner by failing to consider what will happen
when obvious extensions to the feature are attempted.  Whether the
present patch is self-consistent is not the question --- the question
is do we have a self-consistent vision of how we will later do the
other stuff like renaming, changing column type, etc.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: bug in prepared statements, alter table <8.3
Next
From: Tom Lane
Date:
Subject: Re: bug in prepared statements, alter table <8.3