Re: pg_dump output portability

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
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 output portability
Date: 2002-08-14 22:05:36
Message-ID: Pine.LNX.4.44.0208142118530.20055-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> Most of these look like they would break a lot of people --- for
> example, we can't just arbitrarily change the results of bool_out.

That wouldn't help anyway. I meant to add code in pg_dump (and possibly
the rule recompiler). That doesn't break anything.

> You mean you'd rather eliminate the -N behavior, no? I'd vote for that.

Yes. Or at least switch the default to "portable and readable".

> Again, I'm fairly suspicious of this; it seems likely to result in
> failures to read in the data. You can't just leave data newlines as-is
> for example.

Why not? You'd end up with

INSERT ... VALUES ('multi
line
literal', 'more data');

This is accepted by PostgreSQL now, is legal SQL, and is arguably at least
as readable as octal escape sequences. (Note I'm not talking about doing
this in COPY, which is not portable anyway.)

> > * The expression reverse-engineering code outputs ::text and similar casts
> > in many cases. These should be CAST().
>
> I will vote against this as being a major loss of legibility. Perhaps
> we could compromise on controlling it by a GUC variable, though.

I was afraid of that, but to pick up the theme of the day, I'm not sure if
I want to overcomplexify things that much. ;-)

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-08-14 22:18:04 Re: encrypted passwords
Previous Message Robert Kernell 2002-08-14 22:05:26 Fwd: Re: journaling in contrib ...