Re: Errors regarding transporting database using pg_dump

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Errors regarding transporting database using pg_dump
Дата
Msg-id 7558.1254754322@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Errors regarding transporting database using pg_dump  (Chun-fan Ivan Liao <ivan@ivangelion.tw>)
Список pgsql-general
Chun-fan Ivan Liao <ivan@ivangelion.tw> writes:
> STATEMENT:  CREATE FUNCTION "system"(cstring) RETURNS integer
>             AS '/lib/libc.so.7', 'system'
>             LANGUAGE c STRICT;

This hack doesn't work any more --- not that it was ever considered
supported or recommended.  If you really need such a thing, I'd
suggest writing a plperlu or pltclu or plpythonu (according to taste)
wrapper around system().  But do you really need it, or is this just
cruft left over in your database from some playing around?  If the
latter, just ignore this error.

> ERROR:  value too long for type character varying(12)
> CONTEXT:  COPY stulist, line 46803, column STU_CNAME: "鷓埥(9debacdd)砆"

This one looks like it might be an encoding issue.  What database
encoding did you have in the old server, and did you reproduce it
in the new one?

[ ... counts characters ... ]  although frankly that looks like it'd be
more than 12 characters by *anyone's* accounting.  Peculiar.  Maybe the
dump file got mangled while being copied over?

            regards, tom lane

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

Предыдущее
От: Stuart Bishop
Дата:
Сообщение: Re: attempted to lock invisible tuple - PG 8.4.1
Следующее
От: Joshua Berry
Дата:
Сообщение: Limiting the impact of schema additions/poor queries made by clients on production machines