	I know that we're all in end-of-release hurry, but I've got a quick
question.

	We've got some machines that had postgres installed in /usr/local/pgsql
and we are moving their data directories, wholesale, onto machines with
postgres in the standard RedHat locations.  This works just fine except
for the hardcoded-ness of the plpgsql_call_handler having been
previously set to /usr/local/pgsql/lib/plpgsql.so

	Will I destroy things if I execute
update pg_proc set probin = '/usr/lib/pgsql/plpgsql.so' where proname = 'plpgsql_call_handler';

	On the machines?  This seems to work, but I wanted to see if anyone
out there wanted to tell me about this being a really stupid idea.

-- 
Adam Haberlach         |  "When your product is stolen by thieves, you
adam@mediariffic.com   |  have a police problem.  When it is stolen by
http://mediariffic.com |  millions of honest customers, you have a
                       |  marketing problem."  - George Gilder

Fri, 27 Jun 2003 14:07:47 -0700
Adam Haberlach <adam@newsnipple.com>
Manual fixing of plpgsql_call_handler binary location -- good idea?
Adam Haberlach <adam@newsnipple.com> writes:
> 	Will I destroy things if I execute
> update pg_proc set probin = '/usr/lib/pgsql/plpgsql.so' where proname = 'plpgsql_call_handler';

Nope ... that's what I'd probably do.  You could alternatively use
CREATE OR REPLACE FUNCTION if you wanted to be pure, but I'd say that
that creates as many opportunities to make mistakes as it removes, since
you'd have to be careful to get all the other attributes right too.

			regards, tom lane

Fri, 27 Jun 2003 20:21:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Manual fixing of plpgsql_call_handler binary location -- good
	idea?
> > 	Will I destroy things if I execute
> > update pg_proc set probin = '/usr/lib/pgsql/plpgsql.so' where proname = 'plpgsql_call_handler';
>
> Nope ... that's what I'd probably do.  You could alternatively use
> CREATE OR REPLACE FUNCTION if you wanted to be pure, but I'd say that
> that creates as many opportunities to make mistakes as it removes, since
> you'd have to be careful to get all the other attributes right too.

Even better change it to '$libdir/plpgsql.so'.

Chris



Sat, 28 Jun 2003 13:01:18 +0800 (WST)
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Manual fixing of plpgsql_call_handler binary location
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>>> Will I destroy things if I execute
>>> update pg_proc set probin = '/usr/lib/pgsql/plpgsql.so' where proname = 'plpgsql_call_handler';
>> 
>> Nope ... that's what I'd probably do.

> Even better change it to '$libdir/plpgsql.so'.

Good point.  In fact the really preferred spelling (which you'd get from
a fresh 'createlang' run) is just '$libdir/plpgsql'.  Both the path and
the shlib extension are better left to the backend to supply than to
hardwire in.  I'm possibly more aware of this than most folk, since I
like to use HPUX which spells the shlib extension ".sl" ...

			regards, tom lane

Sat, 28 Jun 2003 01:25:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Manual fixing of plpgsql_call_handler binary location 
On Sat, Jun 28, 2003 at 01:25:12AM -0400, Tom Lane wrote:
> Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> >>> Will I destroy things if I execute
> >>> update pg_proc set probin = '/usr/lib/pgsql/plpgsql.so' where proname = 'plpgsql_call_handler';
> >> 
> >> Nope ... that's what I'd probably do.
> 
> > Even better change it to '$libdir/plpgsql.so'.
> 
> Good point.  In fact the really preferred spelling (which you'd get from
> a fresh 'createlang' run) is just '$libdir/plpgsql'.  Both the path and
> the shlib extension are better left to the backend to supply than to
> hardwire in.  I'm possibly more aware of this than most folk, since I
> like to use HPUX which spells the shlib extension ".sl" ...

	Awesome -- I've questioned to myself the wisdom of having this sort
of thing hardcoded, but it looks like it's already been solved.

Thanks, all...

-- 
Adam Haberlach         |  "When your product is stolen by thieves, you
adam@mediariffic.com   |  have a police problem.  When it is stolen by
http://mediariffic.com |  millions of honest customers, you have a
                       |  marketing problem."  - George Gilder

Sat, 28 Jun 2003 11:23:09 -0700
Adam Haberlach <adam@newsnipple.com>
Re: Manual fixing of plpgsql_call_handler binary location