Re: Allow CREATE OR REPLACE VIEW to rename the columns

From: btfujiitkp <btfujiitkp(at)oss(dot)nttdata(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow CREATE OR REPLACE VIEW to rename the columns
Date: 2019-11-06 07:14:09
Message-ID: f9dcdef78c124517edc9e5e5880f651e@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2019-10-31 21:01 に Fujii Masao さんは書きました:
> On Thu, Oct 31, 2019 at 7:59 PM Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>
> wrote:
>>
>>
>>
>> On Thu, Oct 31, 2019 at 12:32 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
>> wrote:
>>>
>>> On Thu, Oct 31, 2019 at 1:42 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> >
>>> > Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>>> > > Currently CREATE OR REPLACE VIEW command fails if the column names
>>> > > are changed.
>>> >
>>> > That is, I believe, intentional. It's an effective aid to catching
>>> > mistakes in view redefinitions, such as misaligning the new set of
>>> > columns relative to the old. That's particularly important given
>>> > that we allow you to add columns during CREATE OR REPLACE VIEW.
>>> > Consider the oversimplified case where you start with
>>> >
>>> > CREATE VIEW v AS SELECT 1 AS x, 2 AS y;
>>> >
>>> > and you want to add a column z, and you get sloppy and write
>>> >
>>> > CREATE OR REPLACE VIEW v AS SELECT 1 AS x, 3 AS z, 2 AS y;
>>> >
>>> > If we did not throw an error on this, references that formerly
>>> > pointed to column y would now point to z (as that's still attnum 2),
>>> > which is highly unlikely to be what you wanted.
>>>
>>> This example makes me wonder if the addtion of column by
>>> CREATE OR REPLACE VIEW also has the same (or even worse) issue.
>>> That is, it may increase the oppotunity for users' mistake.
>>> I'm thinking the case where users mistakenly added new column
>>> into the view when replacing the view definition. This mistake can
>>> happen because CREATE OR REPLACE VIEW allows new column to
>>> be added. But what's the worse is that, currently there is no way to
>>> drop the column from the view, except recreation of the view.
>>> Neither CREATE OR REPLACE VIEW nor ALTER TABLE support
>>> the drop of the column from the view. So, to fix the mistake,
>>> users would need to drop the view itself and recreate it. If there
>>> are
>>> some objects depending the view, they also might need to be
>>> recreated.
>>> This looks not good. Since the feature has been supported,
>>> it's too late to say that, though...
>>>
>>> At least, the support for ALTER VIEW DROP COLUMN might be
>>> necessary to alleviate that situation.
>>>
>>
>> - Is this intentional not implemented the "RENAME COLUMN" statement
>> for
>> VIEW because it is implemented for Materialized View?
>
> Not sure that, but Tom's suggestion to support ALTER VIEW RENAME COLUMN
> sounds reasonable whether we support the rename of columns when
> replacing
> the view definition, or not. Attached is the patch that adds support
> for
> ALTER VIEW RENAME COLUMN command.
>
>> I have made just a similar
>> change to view and it works.
>
> Yeah, ISTM that we made the same patch at the same time. You changed
> gram.y,
> but I added the following changes additionally.
>
> - Update the doc
> - Add HINT message emit when CRAETE OR REPLACE VIEW fails to rename the
> columns
> - Update tab-complete.c

I review your patch, and then I found that tab complete of "alter
materialized view" is also not enough.
So, I made a small patch referencing your patch.

Regards,

Attachment Content-Type Size
alter_materialized_view.patch text/x-diff 1.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-11-06 07:15:00 Re: Logical replication wal sender timestamp bug
Previous Message Amit Kapila 2019-11-06 06:44:42 Re: cost based vacuum (parallel)