Right. Like, you can absolutely do this. If you need single tables, you can
technically set pgdump to include or exclude tables. Be warned though that
this is extremely dangerous as it will not copy over any linked tables and
I don't think it does sequences associated with those tables either.
Basi
On 1/23/21 6:52 AM, sivapostg...@yahoo.com wrote:
We are an ISV. I agree the risk involved in sharing the data. Still few
of my customers need that facility and are accustomed to it when using SQL
Server. On switch over to PG, I face this issue as a limitation. Need to
find and provide a s
We are an ISV. I agree the risk involved in sharing the data. Still few of
my customers need that facility and are accustomed to it when using SQL Server.
On switch over to PG, I face this issue as a limitation. Need to find and
provide a solution.
For those customers, having good volume
On 22/01/21, Benedict Holland (benedict.m.holl...@gmail.com) wrote:
> Sometimes it is easier to simply > replicate the existing bad process
> that a team agrees to rather than making > a better process.
As Alvar Aalto said in a lecture at MIT
It is not by temporary building that Parthenon com
No. Just no. I is fine to make stored procedure changes in a development
environment and deploy them as part of a release. Typically you would want
some sort of change tracking software like alembic or squitch or something
like that. Production databases typically contain a huge amount of data or
d
On 22/01/21, Benedict Holland (benedict.m.holl...@gmail.com) wrote:
> I mean... the best? You just laid out a bunch of steps to define a process.
>
> > On Thu, Jan 21, 2021 at 11:12 PM sivapostg...@yahoo.com <
> > sivapostg...@yahoo.com> wrote:
> >
> >> So the solution to the issue will be
> >>
>
I mean... the best? You just laid out a bunch of steps to define a process.
I will tell you that this sounds like a bad process and that there are
easier ways to make changes like inside of a transaction or backing up a
database before making changes or creating a table replication job, making
chan
On Thu, Jan 21, 2021 at 11:12 PM sivapostg...@yahoo.com <
sivapostg...@yahoo.com> wrote:
> So the solution to the issue will be
>
> 1. Backup a DB using PGDUMP from 1st server.
> 2. Restore the DB in 2nd server.
> 3. Make required changes in the 2nd server.
> 4. Backup that DB using PGDUMP fro
So the solution to the issue will be
1. Backup a DB using PGDUMP from 1st server.2. Restore the DB in 2nd
server.3. Make required changes in the 2nd server.4. Backup that DB using
PGDUMP from 2nd server.5. Delete / Rename that DB in the 1st server6. Restore
that DB in the 1st server.7. W
On Thu, Jan 21, 2021 at 5:52 AM sivapostg...@yahoo.com <
sivapostg...@yahoo.com> wrote:
> create database is to create a new database. If we switch to new
> database, we need to change the new databasename in the program(s) that
> access this database.
>
> If you are just concerned about having t
Pg_dump and pg_restore are what you want. They create sql files that you
pass around.
But seriously, if you have two servers running, replicate one or have your
application point to a server address that you can direct via dns to
whatever active one you want. Postgres makes replication simple. The
create database is to create a new database. If we switch to new database, we
need to change the new databasename in the program(s) that access this
database.
Is there any way to overwrite the data ?
On Thursday, 21 January, 2021, 07:12:19 pm IST, Ray O'Donnell
wrote:
On 21/01/202
Pg_dump does what you want but you could also set up replication.
Thanks,
Ben
On Thu, Jan 21, 2021, 8:42 AM Ray O'Donnell wrote:
> On 21/01/2021 13:13, sivapostg...@yahoo.com wrote:
> > Hello,
> >
> > I'm from SQL Server now developing my current project using PG.
> >
> > In our earlier project
On 21/01/2021 13:13, sivapostg...@yahoo.com wrote:
Hello,
I'm from SQL Server now developing my current project using PG.
In our earlier project(s), we used to copy the database from one server
to another, work in another server, and re-copy it in the original
server. All happened easily wi
In SQLServer each db has its own data file and transaction log file and hence
can be copied the way you described.
> Limitation of Backup utility. Transfer to another server was done
> successfully. When we want to re-copy to original server,
>we have to delete the original db in the original se
Hello,
I'm from SQL Server now developing my current project using PG.
In our earlier project(s), we used to copy the database from one server to
another, work in another server, and re-copy it in the original server. All
happened easily with just transferring the two files (mdf & ldf) to our
16 matches
Mail list logo
