Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux