Re: [GENERAL] CLONE DATABASE (with copy on write?)

2011-11-16 Thread Clark C. Evans
After this discussion and the spin-off discussion on the hacker list, I wanted to summarize my understanding. So, what I asked for is relatively inexpensive way to make copies of an existing database for staging, upgrade tests, and other activities. There are two approaches to this sort of replic

Re: [GENERAL] CLONE DATABASE (with copy on write?)

2011-11-13 Thread Clark C. Evans
On Sunday, November 13, 2011 7:33 AM, "Simon Riggs" wrote: > On Sat, Nov 12, 2011 at 9:40 PM, Clark C. Evans > > [We] should be using "CREATE DATABASE ... WITH TEMPLATE". > > However, this has two big disadvantages.  First, it only works > > if you ca

[GENERAL] CLONE DATABASE (with copy on write?)

2011-11-12 Thread Clark C. Evans
Hello all! Our company has some headaches in our application development and deployment process. The chief problem is, "creating stages", which to this audience is, cloning a database efficiently, making and testing a few changes, perhaps recording the differences between databases, and then

Re: [GENERAL] More then 1600 columns?

2010-11-12 Thread Clark C. Evans
Tom, Thank you for the helpful response. It is very reasonable for the PostgreSQL developers to decide this isn't a common enough problem to justify the effort to change and/or the runtime cost. For example, I'd rather advocate for other features myself (such as CUBE). The solution "in the f

Re: [GENERAL] More then 1600 columns?

2010-11-12 Thread Clark C. Evans
On Fri, 12 Nov 2010 21:10 +, "Dann Corbit" wrote: > If (for access) the single table seems simpler, then > a view can be used. Even if you "partition" the columns in the instrument over N tables, you still can't query it in a single result set. The limit is quite deep in PostgreSQL and ex

Re: [GENERAL] More then 1600 columns?

2010-11-12 Thread Clark C. Evans
On Fri, 12 Nov 2010, Tom Lane wrote: > Generally, wanting more than a few dozen columns is a > good sign that you need to rethink your schema design. > What are you trying to accomplish exactly? Generally speaking, yes. However, survey instruments are a very legitimate design where this is not

[GENERAL] Interaction Record (Journal Table?)

2001-08-31 Thread Clark C . Evans
I was thinking that for the application I'm working on, it'd be nice to have a journal (as an XML fragment) which describes the interactions within the database... 3493 Clark Evans Cameron I was wondering if anyone has done something simi

[GENERAL] Interaction Record (Journal Table?)

2001-08-26 Thread Clark C . Evans
I was thinking that for the application I'm working on, it'd be nice to have a journal (as an XML fragment) which describes the interactions within the database... 3493 Clark Evans Cameron I was wondering if anyone has done something simi

Re: [GENERAL] How do you live without OUTER joins?

2000-01-12 Thread Clark C. Evans
On Tue, 11 Jan 2000, Bruce Bantos wrote: > In my current Oracle DB, I have a number of "lookup" tables > that contain something like this: You make a "lookup" function, and you call the function in your select list. It's been a few months since I've played with PostgreSQL, so I don't remem

Re: [GENERAL] Future of PostgreSQL

1999-12-25 Thread Clark C. Evans
On Sat, 25 Dec 1999, Bruce Momjian wrote: > > On Sat, 25 Dec 1999, Bruce Momjian wrote: > > > My big question is, what new challenges will we face as > > > we become more popular? > > > > Plug-in Oracle 7 compatibility. > > I believe we are adding Oracle compatibility as possible. We are > wor

Re: [GENERAL] Future of PostgreSQL

1999-12-25 Thread Clark C. Evans
On Sat, 25 Dec 1999, Bruce Momjian wrote: > My big question is, what new challenges will we face as > we become more popular? Plug-in Oracle 7 compatibility.