From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump and backslash escapes |
Date: | 2006-05-17 03:58:24 |
Message-ID: | 200605170358.k4H3wOc24823@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I have seen no reply to my suggestion below, so I assume it is the way
> > people want to go for 7.3, 7.4, and 8.0.
>
> I'm not particularly for it, if that's what you meant, and certainly not
> for hacking up old branches that way. For one thing, you can't
> retroactively cause servers that are already out there to not spit
> errors for GUC variables they've not heard of; and even if you had such
> a time-travel machine at hand, it's far from clear that it'd be a good
> idea.
>
> The pg_dump philosophy for cross-version updates is generally that the
> dump should load if you are willing to ignore errors and press on. Not
> that there will never be errors. See for example our previous handling
> of the without_oids business, or search_path, or tablespaces.
So, we should SET the variables and allow people to get the errors on
load? And not supress them from the client and server logs? Is that
better than suppressing them?
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | David Wheeler | 2006-05-17 03:59:21 | Re: PL/pgSQL 'i = i + 1' Syntax |
Previous Message | Tom Lane | 2006-05-17 03:51:51 | Re: PL/pgSQL 'i = i + 1' Syntax |