Re: Upgrade to 9.1 causing function problem - Mailing list pgsql-general

From Willem Buitendyk
Subject Re: Upgrade to 9.1 causing function problem
Date
Msg-id 63CA08D4-5A2F-4924-8BAD-515A9A7FDB91@pcfish.ca
Whole thread Raw
In response to Re: Upgrade to 9.1 causing function problem  (Adrian Klaver <adrian.klaver@gmail.com>)
List pgsql-general
I tried as you suggested and my results are:

crabby=# SELECT length(schema_name), schema_name from information_schema.schemat
a;
 length |    schema_name
--------+--------------------
      8 | pg_toast
      9 | pg_temp_1
     15 | pg_toast_temp_1
     10 | pg_catalog
      6 | public
     18 | information_schema
      8 | crabdata
(7 rows)


So it seems that crabdata schema is not with extra space character or such.  Likewise I created another schema earlier
ina test (called test) from psql and it exhibited the same behaviour. 
I've spent a whole week migrating from 8.3 to 9.1 and am loathe to repeat the process because I might have a funky
installation. In all other respects everything 
seems to work ok.  Failing all else I can try a re-installation.  If I go down this road are there any suggestions to
wipethe slate clean to give myself 
the best fighting chance of having this work?  Using windows 7 64 bit with postgresql 9.1 32 bit and postgis.  I am
alsomaking sure to operate from the correct database. 

Here are the two problems as such:

1) setting the search_path to another schema returns the error in the server log:

2012-02-24 11:32:59.456 PST @[3868]: WARNING:  invalid value for parameter "search_path": "crabdata, public"
2012-02-24 11:32:59.456 PST @[3868]: DETAIL:  schema "crabdata" does not exist

As noted at the beginning of this post - crabdata is clearly present and does not contain any extraneous characters.

2) using designated schema designation in functions and tables still fail to work correctly.  Such as:

select crabdata._crab_set_report_month('2012-01-01');

CREATE OR REPLACE FUNCTION crabdata._crab_set_report_month(date)
  RETURNS void AS
$BODY$

BEGIN

update activity_month set action_month = $1;
perform * from _crab_pop_tag_day_over();

END;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION crabdata._crab_set_report_month(date)
  OWNER TO postgres;
GRANT EXECUTE ON FUNCTION crabdata._crab_set_report_month(date) TO public;
GRANT EXECUTE ON FUNCTION crabdata._crab_set_report_month(date) TO postgres;


CREATE TABLE crabdata.activity_month
(
  action_month date NOT NULL,
  CONSTRAINT idkeymonth PRIMARY KEY (action_month )
)
WITH (
  OIDS=FALSE
);
ALTER TABLE crabdata.activity_month
  OWNER TO postgres;
GRANT ALL ON TABLE crabdata.activity_month TO postgres;
GRANT ALL ON TABLE crabdata.activity_month TO public;














On 2012-02-23, at 6:04 PM, Adrian Klaver wrote:

> On Thursday, February 23, 2012 1:53:42 pm Willem Buitendyk wrote:
>> Both via psql and PgAdmin.
>>
>> Yes only one database cluster.
>>
>
> Another thought.
> Did you CREATE the schema using PgAdmin and if so,  might you have inadvertently
> put in a trailing or leading space ?
> I ask because if I remember correctly PgAdmin by default quotes object names and
> that would trap the space character.
>
> I know  you showed this previously:
>
> "crabby";"crabdata";"postgres";"";"";"";""
>
> On the chance that spaces where trimmed out of the above what does the query
> below show?:
>
> SELECT length(schema_name), schema_name from information_schema.schemata;
>
> --
> Adrian Klaver
> adrian.klaver@gmail.com


pgsql-general by date:

Previous
From: Prashant Bharucha
Date:
Subject: Maxium Share Memory in Debian 64bit
Next
From: John R Pierce
Date:
Subject: Re: Maxium Share Memory in Debian 64bit