Re: Using a VIEW as a temporary mechanism for renaming a table

From: Andy Colson <andy(at)squeakycode(dot)net>
To: Ben Buckman <ben(at)shyp(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Using a VIEW as a temporary mechanism for renaming a table
Date: 2016-06-08 20:08:33
Message-ID: 87543450-647f-d697-04cf-81890ba02452@squeakycode.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 6/8/2016 2:57 PM, Ben Buckman wrote:
> Thanks Andy.
>
> My understanding, and please correct me if I'm wrong, is that the view
> will effectively inherit the table's constraints, because writes to the
> view that can't be written to the table will fail on the table. Re:
> "will the data be good data," what risks should I be considering?
>
> In terms of rollout, we would 1) create the view, 2) deploy code that
> uses the new [view] name, 3) drop the view and rename the table.
> Deployments are "rolling" so there would be no downtime. The app and
> users shouldn't notice/care if they're hitting the table or the view.
>
> Thank you

I'd assumed new version of app would have new columns in the table.
That's what I meant by good data. New columns would not get populated
by the old app.

But if the table structure isn't changing, then I'd say your plan sounds
like it should work. I've never tried it, personally, but I would if I
were in the same boat.

-Andy

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andy Colson 2016-06-08 20:24:27 Re: Using a VIEW as a temporary mechanism for renaming a table
Previous Message Ben Buckman 2016-06-08 19:57:24 Re: Using a VIEW as a temporary mechanism for renaming a table