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
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 |