pg_dump output portability

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема pg_dump output portability
Дата
Msg-id Pine.LNX.4.44.0208141851320.20055-100000@localhost.localdomain
обсуждение исходный текст
Ответы Re: pg_dump output portability
Re: pg_dump output portability
Re: pg_dump output portability
Список pgsql-hackers
I needed to move a PostgreSQL database to another product but I noticed
that the pg_dump output contains a few artifacts that make the output
nonportable.  Most of these should be relatively easy to fix.  Here's my
list:

* Boolean values should be dumped as true and false (rather than 't' and
'f') in INSERT-style output.

* Numeric and int8 should be dumped without quotes, except in cases like
'NaN'.

* Date, time, and timestamp literals should use standard prefixed syntax
like DATE 'yyyy-mm-dd'.

* Identifier quoting seems to be inconsistent.  The -n option gives you
portable behaviour (quoted only if mixed case or funny characters), but
the default -N doesn't actually quote some things that are generated by
the backend, including rule and index creation commands.  Is there a point
in having the -n behavior at all?

* Nonprintable characters in string literals are currently output as octal
escape sequences (e.g., \012).  It would be more portable to just print
out the characters as is.  This should be an option -- any opinions on
which might be a better default?

* The expression reverse-engineering code outputs ::text and similar casts
in many cases.  These should be CAST().

* It was once proposed to make SET SESSION AUTHORIZATION the default in
pg_dump.  What became of that?

* Is anyone working on using standard foreign key creation commands
instead of CREATE CONSTRAINT TRIGGER?

-- 
Peter Eisentraut   peter_e@gmx.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: CREATE CONSTRAINT TRIGGER appears to be a security hole
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Open 7.3 items