From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | Tony Caduto <tony_caduto(at)amsoftwaredesign(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 8.1 and syntax checking at create time |
Date: | 2005-08-31 19:17:49 |
Message-ID: | 3917.1125515869@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> Are you using a database that was restored from an earlier version
> of PostgreSQL? I wonder if you're not getting the lanvalidator
> function.
Ah-hah, that sounds like a good theory. He'd have had to have carried
the DB forward from 7.4 or before, though, since plpgsql had a validator
in 8.0.
We've had repeated problems with PL languages stemming from the fact
that pg_dump dumps them at a pretty low semantic level. Aside from this
problem with adding a validator, we used to have issues with hardwired
paths to the shared libraries in the CREATE FUNCTION commands. And in
8.1, whether the functions are in "public" or "pg_catalog" is going to
vary across installations depending on whether the language was restored
from a dump or not.
I wonder if we could change the dump representation to abstract out the
knowledge encapsulated in "createlang". I don't suppose this would
work:
\! createlang plpgsql <dbname>
but it'd be nice if the dump didn't know any more about the language
than its name, and didn't mention the implementation functions at all.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Miller | 2005-08-31 19:18:58 | Re: 8.1 and syntax checking at create time |
Previous Message | Tony Caduto | 2005-08-31 19:14:11 | Re: 8.1 and syntax checking at create time |