| 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: | Whole Thread | Raw Message | 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) |