Thread

1. Manual fixing of plpgsql_call_handler binary location -- good idea?

   Adam Haberlach <adam@newsnipple.com> — 2003-06-27T21:07:47Z

   	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
   
   

2. Re: Manual fixing of plpgsql_call_handler binary location -- good idea?

   Tom Lane <tgl@sss.pgh.pa.us> — 2003-06-28T00:21:12Z

   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
   
   

3. Re: Manual fixing of plpgsql_call_handler binary location

   Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2003-06-28T05:01:18Z

   > > 	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
   
   
   
   

4. Re: Manual fixing of plpgsql_call_handler binary location

   Tom Lane <tgl@sss.pgh.pa.us> — 2003-06-28T05:25:12Z

   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
   
   

5. Re: Manual fixing of plpgsql_call_handler binary location

   Adam Haberlach <adam@newsnipple.com> — 2003-06-28T18:23:09Z

   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