Re: Errors regarding transporting database using pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chun-fan Ivan Liao <ivan(at)ivangelion(dot)tw>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Errors regarding transporting database using pg_dump
Date: 2009-10-05 14:52:02
Message-ID: 7558.1254754322@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Chun-fan Ivan Liao <ivan(at)ivangelion(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joshua Berry 2009-10-05 15:04:06 Limiting the impact of schema additions/poor queries made by clients on production machines
Previous Message Martijn van Oosterhout 2009-10-05 14:34:34 Re: Errors regarding transporting database using pg_dump