From: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
---|---|
To: | "Markhof, Ingolf" <ingolf(dot)markhof(at)de(dot)verizon(dot)com> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: dealing with dependencies |
Date: | 2021-07-23 10:11:15 |
Message-ID: | CAKoxK+79WJNTmj=FXu_NXCWUOkC7VDxnXYP5z=N=YY1xe-oJeQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Jul 16, 2021 at 2:43 PM Markhof, Ingolf
<ingolf(dot)markhof(at)de(dot)verizon(dot)com> wrote:
> I wonder how you deal with it in a professional way. Sounds like some type of "make" (that UNIX tool dealing with dependencies in the context of e.g. programming in C) would be helpful...
>
I see this question coming out very often, and quite frankly I'm not
able to fully understand it.
I think you will have your view (and more in general, object)
definitions into some kind of source control management, so adding or
removing columns from the table could be easily reproduced into the
view.
If you don't have the view source code (that is what often I'm argued
with), you can always use pg_get_viewdef() to get the source code
(adding some more machinery to get all the details).
At least you don't find your application running into errors because a
view (or a trigger) has not compiled (and that happened to me in
Oracle).
And my vote goes to sqitch for deployment and change management
<http://sqitch.org/> (and guess what? it works with Oracle too).
Luca
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2021-07-23 11:04:39 | Re: pg_dumpall with individual output files per database? |
Previous Message | Luca Ferrari | 2021-07-23 10:05:19 | Re: pg_dumpall with individual output files per database? |