From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joseph Shraibman <jks(at)selectacast(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Auto-timestamp generator (attached) |
Date: | 2001-02-09 00:59:32 |
Message-ID: | 15079.981680372@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Joseph Shraibman <jks(at)selectacast(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alfonso Peniche | 2001-02-09 01:03:18 | Re: About SP's and parameters |
Previous Message | Joseph Shraibman | 2001-02-09 00:54:45 | Re: Auto-timestamp generator (attached) |