Re: BUG #5642: pg_upgrade does not handle shared libraries for language handlers

Thank you. I believe we had implemented version 6.x of Postgres back when
Postgres had stored procedures, views, triggers, etc. and MySQL didn't. I
said that I had no intention of using a database without views so we went
with Postgres. Even our Configuration Management Software vendor has
selected Postgres for their next version of software. They had been placing
metadata in their proprietary repository and it was becoming a bottleneck
since the metadata could not be indexed and they basically did the
equivalent of a table scan for every query. They have modified their C
daemon to insert records and delete records from a Postgres database and
used triggers and stored procedures to capture history. They chose Postgres
because it performed rings around the other open source dbs. Procedures
that could take 30 minutes to run now run in less than 10 seconds with
tables with 140,000,000 rows.

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Tuesday, September 07, 2010 11:17 PM
To: David Platt
Cc: 'Bruce Momjian'; pgsql-bugs(at)postgresql(dot)org
Subject: Re: [BUGS] BUG #5642: pg_upgrade does not handle shared libraries
for language handlers

"David Platt" <davidplatt(at)davidplatt(dot)com> writes:
> No, that was defined in the database through pg_dump, edit the path, the
> loading the pg_dump using psql. For each time the database has been
> upgraded.

> We started using Postgres in 2000 and even plpgsql had to be created as a
> language back then, there was no creation by default. Evidently the
> documentation indicated that the path to the shared library had to be
> declared because I don't remember any example showing $library.

$libdir was implemented in 2001, so you've been doing it the hard way
for awhile :-(. However, I don't immediately find anything in the
release notes suggesting that people change to using that, so it's
definitely not all your fault.

regards, tom lane