Thread: Manual fixing of plpgsql_call_handler binary location -- good idea?
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." - GeorgeGilder
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
> > 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
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
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." - GeorgeGilder