Skip site navigation (1) Skip section navigation (2)

Re: Backup with Java

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com>, Postgres JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Backup with Java
Date: 2006-12-01 15:45:21
Message-ID: 74102F1D-AE50-4EBF-9CD5-6A1CCC6B8FBC@fastcrypt.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
So back to Marc's request, it would seem that making pg_dump do  
something predictable if specifically requested to do so would  
alleviate Marc's problem ?

Dave
On 1-Dec-06, at 10:27 AM, Tom Lane wrote:

> Csaba Nagy <nagy(at)ecircle-ag(dot)com> writes:
>> Actually, if there were a working and maintained pg_upgrade, I'm  
>> pretty
>> sure nobody would use pg_dump as an upgrade facility anymore.
>
> You think so eh?  Hint: the only workable design I've seen for  
> pg_upgrade
> uses pg_dump as a component.  It's much easier to handle
> version-to-version changes in pg_dump than it would be inside the  
> server.
> Example: there is no way that a pre-8.1 server could be expected to  
> know
> that it had better set standard_conforming_strings = off to ensure  
> that
> the SQL it's emitting will be understood properly by a post-8.3  
> server.
>
> 			regards, tom lane
>
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo(at)postgresql(dot)org so that  
> your
>        message can get through to the mailing list cleanly
>


In response to

pgsql-jdbc by date

Next:From: Mark LewisDate: 2006-12-01 16:08:56
Subject: Re: Locking on PGStream.ReceiveChar(PGStream.java:256)
Previous:From: Tom LaneDate: 2006-12-01 15:27:27
Subject: Re: Backup with Java

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group