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 solution.
For those customers, having good volume of data, we're implementing
replication which resolves this issue. For smaller sized database
(company(ies)), they prefer (and we too) this copy and re-copy procedure,
to transfer the data between home and office.
And this pandemic made this a compulsory feature, which they don't want to
loose. This transfer is not a one time job, it gets repeated, which they
have been doing for years. Here security is not a big concern for them.
Portability is the need for them.
Sadly, the architecture of Postgres means that there's no concept of
detaching *a single database*.
If you only have one database in the "cluster" (ancient Postgres term for
"instance"), then you can stop the cluster "-m smart", tar up data/, and
transfer it across. You'll need to have a directory on your dev server,
custom postgresql.conf (that among other things uses a different port
number) and pg_hba.conf files,
TBH, tarring data/ isn't really necessary.
Happiness Always
BKR Sivaprakash
On Friday, 22 January, 2021, 09:28:13 pm IST, Rory Campbell-Lange
<r...@campbell-lange.net> wrote:
On 22/01/21, Benedict Holland (benedict.m.holl...@gmail.com
<mailto: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 comes on Acropolis.
--
Angular momentum makes the world go 'round.
