On 2005-03-03, Markus Schaber <[EMAIL PROTECTED]> wrote:
> - Create the new date in another schema, and then simply rename those
> two schemas for "switch over"
This kind of thing looks superficially attractive but it has some serious
problems if you try and do it while there is other database act
Hi, Casey,
Casey T. Deccio schrieb:
> Building everything in the separate "build" schema works great, but it
> is the DELETE (TRUNCATE won't work when foreign keys point to the table)
Just as an additional info: You could temporarily drop the foreing key
constraints, run TRUNCATE, and recreate t
On Mar 3, 2005, at 1:37 PM, Casey T. Deccio wrote:
On Thu, 2005-03-03 at 08:28 -0700, Markus Schaber wrote:
- Create the new date in another schema, and then simply rename those
two schemas for "switch over"
This worked very well. I created another schema ("build") and
populated
the tables within
Casey T. Deccio wrote:
Question: is there an "easy" way to duplicate an existing schema
(tables, functions, sequences, etc.)--not the data; only the schema?
This way, I would only need to modify one schema (public) to make
changes, and the build schema could be created each time as a duplicate
of t
Hi, Casey,
Casey T. Deccio schrieb:
> Question: is there an "easy" way to duplicate an existing schema
> (tables, functions, sequences, etc.)--not the data; only the schema?
> This way, I would only need to modify one schema (public) to make
> changes, and the build schema could be created each t
On Thu, 2005-03-03 at 08:28 -0700, Markus Schaber wrote:
> - Create the new date in another schema, and then simply rename those
> two schemas for "switch over"
>
This worked very well. I created another schema ("build") and populated
the tables within build. Then:
BEGIN;
ALTER SCHEMA public R
On Thu, 2005-03-03 at 06:23 -0700, Sean Davis wrote:
> Why not rebuild the entire thing in a separate "build" schema then do
> only the stuff like copying tables inside the transaction block:
>
Building everything in the separate "build" schema works great, but it
is the DELETE (TRUNCATE won't wo
Hi, Casey,
Casey T. Deccio schrieb:
> There is more than one problem with this, but the largest is that I
> would like to perform this whole database rebuild within one
> transaction, so other processes that need to access the database can do
> so without noticing the disturbance. However, perfo
]
Sent: Wednesday, March 02, 2005 7:15 PM
To: pgsql-sql@postgresql.org
Subject: [WW Spam: medium] [SQL] Building a database from a flat file
A database I am currently using is built and updated periodically from a
flat csv file (The situation is rather unfortunate, but that's all I
have righ
On Mar 2, 2005, at 7:15 PM, Casey T. Deccio wrote:
A database I am currently using is built and updated periodically from
a
flat csv file (The situation is rather unfortunate, but that's all I
have right now). The schema I use is more complex than the flat file,
so I follow a process to populate
A database I am currently using is built and updated periodically from a
flat csv file (The situation is rather unfortunate, but that's all I
have right now). The schema I use is more complex than the flat file,
so I follow a process to populate the tables with the data from the
file. First I slu
11 matches
Mail list logo
