Joseph Shraibman <jks@selectacast.net> writes:
>> The backend will believe whatever you tell it --- if, say, you restored
>> a 6.5 dump that had a different library path than your current
>> installation, you'd be in trouble. How exactly did you install plpgsql
>> support into this database?
>>
> CREATE FUNCTION "plpgsql_call_handler" ( ) RETURNS opaque AS
> '/usr/lib/pgsql/plpgsql.so' LANGUAGE 'C';
> CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER
> "plpgsql_call_handler" LANCOMPILER 'PL/pgSQL';
> I just cut and pasted without looking at it. Stupid me. That points to
> the 6.5.3 lib that came with redhat.
Ah, that explains a good deal. You were lucky that the 6.5.3 shlib was
just incompatible enough to fail cleanly, and not to do anything really
screwy :-(
BTW, the recommended way to crank up plpgsql or other PL languages is
to use the 'createlang' script, which has a slightly better chance of
getting this sort of detail right.
> playpen2=# select lastchg_addto('foo','c');
> ERROR: parser: parse error at or near "execute"
> Is there something in the script that is not compatible with 7.0.3?
plpgsql's 'execute' feature is new for 7.1 ...
regards, tom lane