Re: pg_dump output portability - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pg_dump output portability
Date
Msg-id Pine.LNX.4.44.0208142118530.20055-100000@localhost.localdomain
Whole thread Raw
In response to Re: pg_dump output portability  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump output portability  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: pg_dump output portability  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@gmx.net



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Open 7.3 items
Next
From: "Robert Kernell"
Date:
Subject: Fwd: Re: journaling in contrib ...