Re: pg_dump output portability

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: pg_dump output portability
Дата
Msg-id Pine.LNX.4.44.0208142118530.20055-100000@localhost.localdomain
обсуждение исходный текст
Ответ на Re: pg_dump output portability  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump output portability
Re: pg_dump output portability
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Open 7.3 items
Следующее
От: "Robert Kernell"
Дата:
Сообщение: Fwd: Re: journaling in contrib ...